The reactions to the recent iPad launch have been fascinating to watch. My personal reaction is kind of mixed. For the last month or so I have been looking at ebook readers and am tempted to get the Kindle. The reader itself is a means to an end for me: its the Amazon library that is really tempting. I have been using the Kindle application on the iPhone and its surprisingly functional, even on the small screen. Given that, its tempting to consider the iPad instead of the Kindle (I would probably never use the Apple Book Store). I am not sure how Amazon’s business model is set up, i.e, is it like the Video Games industry where they make minimum profit on the device itself and more on the content (games for XBox/PS3s and books in Amazon’s case). If its not, Amazon should re-evaluate keeping the Kindle App in the AppStore. From what I read, the iPad’s is probably is.

What I am a little excited about is that the iPad could potentially have a significant impact on the way people consume online content, or at least on how they feel they should be able to consume content. I have seen some great examples of digital magazines that have started emerging and a lot of these rely on touch interfaces. In my mind, this is the main use case for the iPad.

The print media seems to be excited, though note that the Time Inc magazine (video #1) is actually done in Adobe AIR and Flash, something we wont get on the iPad.

That said, the iPad’s usage pattern would be interesting to watch. I dont think it would work for more than a few minutes of browsing at a stretch. It would be a good device to quickly glance over the day’s news and watch a few minutes of video but thats it (I kind of imagine it sitting on my coffee table like any other magazine). iLife for the iPad seems a waste. The iPad is not geared for content creation, heck even typing in emails would be a chore. I do like using more than my index finger when typing anything more than a google search or a url. In terms of content consumption, the device would be awkward to hold for longer than a few minutes. I cannot really imagine using it to consume long form video content at all, though people seem to insist they will love to use it on airplanes etc, I like being able to place the laptop/netbook on the seat table and not stress my arms (or throw your neck out bent over a iPad sitting flat on the table).

The lack of Flash on the device is tragic though. Coupling a rich web technology to the iPad could have raised its utility manifold. Flash has traditionally been used to create richer experiences on the web fairly cheaply. The only option to creating such experiences for the iPad is a fairly expensive native application, which brings its own headaches around things like application updates. For example, as Doug McCune points out, sites that use Flash for data visualization will completely not work on this device. HTML5 may allow for some of that but experiences like embedded video (like the video based navigation in the Sports Illustrated application) are completely ruled out.

This also means a big hole in iPad’s armor. I think I will probably end up waiting for a similar device powered by Android, as long as I can still access the Kindle books there.

In the end, I feel the iPad is specifically geared for one kind of content, and if you get one, will end up using for really short periods of time before going for ur laptop again. Its position in the market isn’t as strong as the iPhone and while lack of certain features like multitasking and Flash were acceptable on a phone, they will get really annoying on this device really fast. In the end, a lot of its success depends on optimized experiences developed by content creators. In any case, I hope it raises the bar for such content as the iPhone did for the phone.

[Update]
Wired’s new IPad application is pretty interesting and done with Adobe AIR that they plan to compile down to an IPad application:

Quotes from the post and counter arguments:

Apple isn’t trying to replace Flash with its own proprietary thing. They’re replacing it with H.264 and HTML5. This is good for everyone but Adobe.

h264 is NOT part of the open web. Its proprietary technology that Apple (and Adobe) happen to license and Apple has adopted that its core media technology. Frankly, there are enough posts out there that indicate Apple may actually want to sabotage the ogg-theora effort, you know, the real open source video codec?

It’s a chicken-and-egg problem. Publishers use Flash for web video because Flash is installed on such a high percentage of clients; clients support Flash because so many publishers use Flash for web video. Apple, with the iPhone, is solving the chicken and egg problem.

It is actually only a problem if you are Apple. End users didnt seem to mind enough to not install or update the players.

[The whole story of the kid not able to play a web game and then...] That there was a period of initial frustration due to Flash games not playing doesn’t change the fact that they (a) bought an iPhone and (b) were set to buy games from the App Store.

They probably were, but a couple maybe. But the kid was not going to get a game every time he got bored of the last one. The story worked out for Apple sure, but not the kid really. Apple didnt start him off in a new direction where he was going to be a lot happier with better games available.

The iPhone’s lack of Flash has not hurt it one bit.

Yeah, neither did having AT&T as a carrier but we all know our sentiment on that.

I’ll leave the last word to Apple COO Tim Cook, who a year ago said, “We believe in the simple, not the complex. We believe that we need to own and control the primary technologies behind the products we make…”

Exactly. Its a battle for ownership of platform. Can people stop saying “Apple is doing this for us”?

P.S
My main coding machine is a Mac and I really like it. I think the IPhone is a fantastic device and the user experience let Apple push its own agenda around video further. Its a deserved win! But for Apple’s proprietary platform.

This is something I thought would take me a couple of hours to implement for the application I am working on but ended up taking way too long validating behavior and the gotchas between the PC and Mac OS’s so its definitely good utility code to keep in your toolbox. The behavior I was trying to mimic was that of apps that run in the background when the main window is closed and then can be re-invoked by clicking on the icon in the dock on the Mac or the system tray in Windows.

First the API, which I am pretty proud of. To get the above behavior, once you have my class included in the classpath, all you need to do is:


AirUtils.runInBackgroundOnClose(window)


Doesn’t get much simpler than that . Optionally you can pass arguments to handle the invoke interaction and conditionally cancel it, an array of Bitmaps to choose from for the icon in the dock or system tray and a NativeMenu object that displays the menu that displays when the user right clicks on the icon. If the Array of Bitmaps is not passed in as a parameter, the code parses the applicationDescriptor XML file and uses the icons defined there (why doesn’t AIR do this by default?)

You can check the code at my AIRUtils Github repo.

Some important points to note:

1) InvokeEvent Gotcha
There were a few gotchas in the implementation. My first pass was something that looked like this:

For some bizarre reason this didnt work at all and debugging it showed that the InvokeEvent was being called multiple times. Turns out the InvokeEvent is unlike any other Event as (as per the docs): “When an event listener registers for an invoke event, it will also receive all invoke events that occurred before the registration”. The fix for that was to check NativeWindow visibility when activating the NativeWindow.

2) Overriding NativeWindow’s Close Event:
Another gotcha here: I wanted to call preventDefault() on the NativeWindow’s Close event, but that meant there was no way to exit the application on a Mac. Why? Because calling NativeApplication.exit called the close action on the NativeWindow which was being preventDefault-ed. So the app would just never exit. To fix this, I had to check if the NativeApplication was exiting when the close event was called and if so, not prevent its default behavior.

3) Loading the icon image from the appDescriptor.xml:
All the icon used in the dock/system tray is pulled from the appDescriptor.xml. The parsing/loading and capturing Bitmap of the icon is probably more work than just using a bitmap embedded in the swf but it made for a cleaner API. Another gotcha when implementing this was that using Loader.load() with a File’s nativePath worked on Windows but not on a Mac. Apparently the right way to load a file into a loader from the filesystem is by using the file’s url property and not the nativePath.

There is a lot of blood sweat and tears behind this product, but its pretty satisfying when you see how much people like it. CIM’s MyDVRManager application for remotely managing your DVR hit Gizmodo yesterday. The service is being rolled out in phases and a good way to check if you may have access to the application is if your on-screen guide has changed to look like the new one as in the video below:

RDVR was also the biggest JavaScript/HTML based RIA I worked on with Chris, Mat and Bonnie (note: I have since moved from being Software Engineer to User Experience Technologist position but the RDVR remains one of my main projects, now from a user experience prototypes point of view) and these guys have done an awesome job with the codebase. Some of the things we used there were:

• JQuery
• ScrewUnit for unit testing
• LessCSS for CSS rules
• An internally custom MVC framework that completely decouples UI from the business logic

So once again, congrats to the CIM CrossPlatform team (Design/IA/Dev/Product/PM and QA). Am anxiously waiting for the app to go live where I live so I can be as happy as this guy here (he is using the manager to manage his Comcast Tivo box, but its the last version of the client application with a different color scheme):

I dont think I have done an end of the year post ever, but 2009 was definitely eventful enough so here goes:

Goodbye Flash Team:
I began 2009 less than super excited. The Flash team I had worked with for the previous 4 years was disbanded in an internal reorg and I was now UI lead for the newly formed Cross Platform Engineering team. The team was going to be responsible for some of the most elaborate Rich Internet Applications to come out of Comcast Interactive Media such as the Remote DVR Manager as well as sites like the Video On Demand channel on Fancast.com, but all programming was done in JavaScript and HTML and no Flash at all. This move turned out to be one of the best things personally, since I was forced to learn HTML/JavaScript beyond the basics I knew till then as well as work a lot closer with some of the smartest engineers at CIM. As a result, today I can honestly say I know it as well as I know Flash which is something I couldn’t say earlier.

Above: The VOD channel on fancast.com uses a lot of JavaScript based interactions like AJAX based tooltips and client side data storage.

My First Patent
This was easily the best thing to happen in 2009. I worked on Comcast’s Fan for 4 years through 4 different versions of the application. And in July, Comcast was awarded a patent on the application and I was one of the 4 people on the author list.

OpenPyro marches on
Work continues on OpenPyro, the Flash framework, and its getting to be pretty cool. The 0.6 release is very close and has a bunch of optimizations like Lists with recycling renderers, a brand new Effects framework, etc. I haven’t talked a lot about OpenPyro in a while but believe me the commits have been going in pretty regularly.

EspressoReader 2.0 cometh
Earlier in the year I released a desktop client for Google Reader called EspressoReader. The application got more popular than I had counted on and unfortunately there were a few bugs that caused a lot of people to not be able to use the application at all. Seeing how many people seemed to like it, I started working on the next version of the application, this one written pretty much from ground up and its coming along pretty nicely. I will start talking about it a lot more in the coming weeks but I have already setup a signup for alpha form at EspressoReader.com.

Moving to User Experience
Finally, towards the end of the year, I formally moved out of Engineering to the User Experience team. The move was fairly drastic for me since I have always been an engineer and am addicted to programming, but the new position was a great opportunity to learn new things as well as build more prototypes. I have always been a fascinated with product development and the new position gets me a lot closer to that.

Anyway, like I said 2009 was definitely eventful and I am really looking forward to 2010, releasing EspressoReader and evolving OpenPyro among other things. Hope you all have a great 2010 as well.