IPad and the era of the digital magazine?

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:

http://c.brightcove.com/services/viewer/federated_f9/1813626064?isVid=1&publisherID=1564549380

Thoughts on DaringFireball’s latest post on Apple and Flash. Lets Call a Spade a Spade can we?

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.

AIR Utility code: Window Management for applications that run in the background

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.

Congratulations to the CIM CrossPlatform team: Comcast’s MyDVRManager gets Gizmodo’d

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):

The obligatory 2009 recap post

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.

Fancast onDemand Tooltips
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.

oEmbed and why its a big deal (specially for video sites)

WordPress version 2.9 came out this week and one of the features that made me sit up and take notice was the new support for oEmbed for embedding content (Thanks Brajeshwar for the link). oEmbed is one of those things that I feel not enough people know about, well at least in my circle. The oEmbed specification basically allows you to query a url and retrieve the significant embedded content on that page. The idea was concepted by Leah Culver (formerly of Pownce, the Twitter on steroids app that didn’t make it) and her announcement post on the spec is a good read to understand more about the idea.

So what this means is, now to embed a video from YouTube (or any other site that supports it) at a page http://www.youtube.com/abcdef, WordPress users dont have to copy paste an embed block of code, they just have to paste the link to the video in their post and WordPress will automatically swap the link with embedded video. While this is convenient for people like me who run our own blogs, its a huge deal for the less technical users on hosted WordPress blogs who may not know how to use the embed blocks or may not be allowed arbitrary html in their posts. Thats a huge deal for syndication! The specification goes beyond video of course and includes any embedded content, like slideshows, presentations etc. And of course WordPress doing this is great but I imagine a lot more applications will start using this feature soon.

I have to admit, after the collapse of Pownce, I thought oEmbed would not go anywhere but the sites listed on the WordPress feature post are a lot of the big players.

oembed

Its great to see a good idea go beyond the product that spawned it.

The Flash Platform continues to amaze me. Check out the fantastic movie: Waltz with Bashir

I just saw Waltz with Bashir, a fantastic animated documentary chronicling Ari Folman’s journey as he tries to regain his lost memories from the 1982 Lebanon War. The direction is fantastic and the story is powerful and shocking and definitely blew me away.

The Wikipedia entry goes a lot more into the details of the movie’s plot and lists it mile-long list of awards. Also check out the Israeli Art Director David Polonsky’s interview here as well as the the trailer of the movie here.

http://www.fancast.com/movies/Waltz-with-Bashir/142253/864195476/Waltz-With-Bashir-Trailer-1/embed?skipTo=0

What I really found interesting is that all the Character animation was done in Flash! Yeah the same platform that powers all those crazy banner ads, apps like Tweetdeck, crazy creative Flash websites etc etc. The Flash animation is combined with some really good CGI and occasionally cell animation to end up telling a deep and powerful story that, according to Ari, could not have been told in any other medium.

The breadth of the platform continues to amaze me and its something we occasionally forget. Fantastic stuff !

Google AppEngine App issues on Snow Leopard

I always seem to trip up on these language version issues. I spent way too much time on this so, as usual with such things, I thought it was worth a post. Early this week I upgraded my work machine (MacBook Pro) and the new machine came packed with Snow Leopard. Today, I had some free time so I figured I’d modify this “lab” project that a few of us worked on at Comcast Interactive Media a few months ago.

I use the GoogleAppEngineLauncher application to start/stop the apps and it seemed to launch fine once I had the code checked out from SVN. However one part of the application, which loaded some remote data and stored it in the DataStore didnt seem to work anymore. Stilling digging through what could have gone wrong, I ended up isolating the issue with the invocation of urllib2. Looking through Google’s documentation, I tried switching to URLFetch which fixed that part. But a couple of lines later, I tripped over another issue. This time the error was a lot more explicit with some message mentioning a missing __init__ in the 2.6 version of Python. So I tried switching the Python location in the /usr/bin/python to the 2.5 version but that didn’t work. Turns out to switch the Python version on the launcher, you have to set the value in the Preferences panel for the application as mentioned here. Ta daa! That worked.

Note, if you are using the command line dev_appserver.py script to run your application, check out this post here

Dispelling the FUD! Silverlight is NOT on the iPhone!

This is crazy, do any of these bloggers actually read the announcements? My Twitter/RSS-feed streams are clogged with Silverlight on the IPhone items like here, here and here, and thats just not the case. So lets please get the facts right: Silverlight IS NOT on the iPhone. Or rather the browser plugin called Silverlight isnt.

Here are the facts. Microsoft User Experience Platform Manager Brian Goldfarb stated:

“We’re translating the content to support the MPEG2 v8 [decoder] format that the iPhone format; we’re moving it to their adaptive streaming format. So it’s the same IIS smooth streaming content, the same server, the same point of origin, but now I can get that content to play without any code changes, without any real work, on the iPhone. That’s the critical thing for our customers.”

Microsoft, Adobe and Apple have all proprietary adaptive streaming formats. For a better understanding read this article on Apple’s adaptive streaming on NewTeeVee.

Now in all honesty, thats cool. So you place a bit of video that silverlight can adaptively stream and if an iphone requests that, IIS will handle that as well. I am not sure but Adobe’s solution may need the Flash Communication Server to step in. But the perception of “free” only works if you are resigned to use IIS anyway, which I am sure a lot of Silverlight shops are anyway. But there is that difference.

However the titles of the posts I read and the followup comment are so WRONG. Silverlight isnt on the iPhone, video that Silverlight could play now plays on the iPhone.

Crazy!

Web applications vs. “real” applications and a thoughts on moving off the webpage browser for apps idea

There is an interesting discussion brewing over a couple of blogs. Part of it began when PPK wrote a rather strongly worded post titled “Apple is not evil. iPhone developers are stupid” where he accused some of the developers jumping into the whole native app for the iphone of not really considering the advantages of HTML5 and the powerful Safari browser on the iPhone for their applications.

Of course the iPhone native app camp had to respond and I am sure there are a few responses now online. The one I found that Aral Balkan linked to was by Faruk AteÅŸ made some points around why the App Store in all its craziness is still worth the pain, but they centered around JavaScript performance (which I dont think is as bad esp for the apps that constitute 90% of the app store), HTML layout issues (which I dont agree with really) and making your application available at a place where users are actually looking for applications (some merit here).

Similar discussions also seem to be happening on the Google Chrome OS front (except that in that case there isnt a real option except web apps). For example, after Chrome’s public demo, in a followup Q and A session, Google’s Sergey Brin responded to a question saying that Chrome OS will not support any native application at all. Apple had encouraged developers to write web apps for the iPhone before the native app SDK was announced, but Sergey seemed to indicate that one reason may have been that Apple’s own native apps seemed to fragment user experience since the native apps felt different than the web ones.

I have to say I have yet to be convinced of the web-apps as native-apps concept. This week I have been halfway in the process of transitioning from one computer to another at work, and I was surprised at how much of my data is already on the cloud, between Google Docs, EverNote, DropBox, Flickr, etc, I had very little actual data to move across. That part of the dream is awesome. But using that data in apps is a different story. For one thing, there are very few guidelines for how web apps should look and work making the look and feel widely different and something that we learn from scrach on every new application. And network latency is often very painfully apparent, and I am not even talking for the data, its probable as you switch from one state of an app to another, you are looking at a blank screen for quite a few seconds before the UI gets loaded in, and then tries to load the data.

In a recent labweek project at CIM, we wrote a web application optimized for the iPhone for browsing Comcast On Demand content. The application, while functional, did not work nearly as elegantly as a native iPhone app especially on a device with spotty connectivity. I shudder to think what would happen if my Google NetBook was on a saturated network like AT&Ts right now. I imagine it would only take a few instances of “waiting…” messages to do something that traditionally was instantaneous to piss of a fair number of users (including me). Add to that html’s behavior of rendering incomplete content which then pops into the final look once images and icons get loaded, poor javascript animation (even if they are because of a poorly written piece of JavaScript code) would make the experience a far cry from what I have gotten used to in native applications like that on OSX or (even) Vista.

Perhaps part of the problem remains that we are trying to overload the browser metaphor. The web browser was written to browse documents, and HTML5 continues to move it in that direction. Maybe what is really needed is what I call an Application Frame, a browser that has no concept of a page. There are a number of features that this would need:

  • A concept of state changes that dont involve the entire page to reload, nor rely on crazy JavaScript dom manipulation. Something that looks, for example, similar to Flex’s States metaphor. The application frame should automatically handle transitions by default unless the developer overrides that.
  • The ability to proactively cache an entire application at the application startup, not just page 1 of a 5 page application
  • Ability to add launch icons to the desktop/start menu (I think JNLP does this right now)
  • Ability to override close action of the window that sends it into a windowless background process mode
  • Notification APIs that allow the application that was set as a background process to be recalled into the window mode
  • Ability to leverage system icons without having to package them into the app

I am sure there are more but these are the ones that come immediately to mind. Note that all this happens without an install process. The end user requests the application from a URI and the server can send back a new HTTP Header (something like Content-Type:Application/FrameContent) and then proceeds to send markup and javascript that defines the app UI. The Application Frame can even keep some browser behavior, like history of recently invoked applications, bookmarks, etc. Also the markup should include html and also higher order markup similar to widgets in, say, XUL or Flex.

Couple these with things that are now becoming part of HTML5 like built in databases and web workers and we could finally realize the dream of a “real” application sent to the end user by a webserver at the time of launch. But until that, I still think the web-application may not do it for me. Chrome may prove me wrong, but thats something time will tell.

Update: PPK has a new post up responding to the avalanche of passionate native app folk. Pretty fair points there.