Thursday, June 24th, 2010

ExtensionFM: A case study on a sexy app, turn extension

Category: Showcase

>Editor’s note: Dan Kantor is the CEO behind the awesome ExtensionFM project. It really pushes the boundaries on what the Web can do, so I asked Dan to give us a mini case study on the project. What follows is his words on the matter. Thanks for taking the time Dan!

Dion recently posted about the march to a more client-centric web. The post hit home with me as the founder of a web-based application that is as much ‘app-like’ as it is ‘web-like’. The promise of the web, and HTML5 in particular, is that we will finally reach the write-once, run-anywhere dream we have all been in search of that neither Java nor Flash could fully deliver. Dion poses this question (and answer) towards the end of the post – ‘As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No.’. I don’t think many developers would argue with Dion’s answer. The real question is – ‘Are we there yet?’

My company is developing a client-centric web-based music player that cuts no corners in its attempt to look, feel and run like a native application. We threw progressive enhancement out the door, pushed the pedal to the HTML5 metal and created something that most people would be hard-pressed to believe is not a native application if they didn’t already see it running inside the browser. However, there is a catch. Our application only runs inside Chrome. This was of course by design. We built it as a Chrome extension. We didn’t choose to do this because we wanted to restrict it to Chrome. We did this because a large part of the functionality of our application needs the extra APIs and permissions an extension gives you. A nice side-effect of that is we know 100% of our users are using an HTML5 capable browser. Chrome extensions are 100% HTML(5), CSS(3) and Javascript. Extensions provide extra Javascript APIs that give you access to functionality that you otherwise would not have running as a website such as removing security restrictions on cross-domain xhr and requiring permission to display desktop notifications. Of the thousands of lines of code in our extension, only 5% of it is Chrome specific. In theory, this should make porting to other browsers and OS’s easy. Let’s see what it looks like in practice.

A few months ago, we decided to see what our application would look like on the iPad. After just four hours, we had a working prototype of our music player that looked and felt native but more importantly looked and felt exactly like our Chrome extension. This was possible because Chrome and Safari share the same rendering engine – Webkit. Mobile Safari has already implemented many of the HTML5 features we needed such as HTML5 Audio, Web Database and Local Storage and many of the CSS3 features we needed such as Background Gradients, Rounded Corners and Box-Shadows. We were able to re-use most of our Javascript code and since we used a lot of CSS in place of images, we were able to resize elements with ease. But a prototype is just a prototype. Could our web-application actually be a viable shipping product on the iPad?

At this point, the answer is no. Mobile Safari has two quirks that seriously hamper its ability to act as a web platform. The first is it’s lack of fixed positioning. If there was one feature that defined native applications vs. web applications it would be that native applications almost always frame content with a top and bottom layer of buttons or displays. Think about iPhone apps. Almost every one of them (minus games) has a navigation layer on top and a series of buttons on the bottom. To pull this off as a web-application, you need fixed positioning. Unfortunately, Mobile Safari (as well as Android’s browser) do not provide this feature. There are many hacks to emulate it though. Apple has even developed a Javascript/CSS framework to get around this themselves. For our iPad web-app, we used a library called TouchScroll that uses Javascript and CSS animations to emulate scrolling. Overall, the lack of fixed positioning is not a game-ender, as hacks are available, but it certainly adds a layer of complexity to building a client-centric web-app that will make many developers’ lives more difficult. The next quirk may just be a game-ender. Mobile Safari on the iPhone and iPad has an annoying ability to refresh windows once you open up a few. So say you have a few windows open including our music player. The music player is not the active window however. When you click back on it to make it active, it refreshes. I’m not sure why this happens although my guess is it has something to do with memory management. Either way, most apps (especially music or video ones) cannot be taken seriously if the application is constantly refreshing. Sure, in theory applications could maintain their state between refreshes. But in practice, this never works quite as well as we’d like it to. Of course, music stopping and starting constantly will be a game-ender. I am hoping that the iPhone 4 with its 512MB RAM does not have this issue. Android does not seem to suffer from this but Android does not support HTML5 Audio or Video so it certainly has drawbacks of its own.

A couple of weeks ago, Safari 5 was introduced with support for extensions. We spent a few hours reading the documentation to see what it would take to port our extension from Chrome to Safari. Unlike Firefox, where extensions are a bit more than just HTML/CSS/JS and support for HTML5 features are lagging, Safari extensions are theoretically similar to Chrome. Other than different Javascript APIs, the functionality offered is almost exactly the same. We determined that it would not be too difficult to port. Of course, business decisions are not always just about technology, so we are waiting a bit before we do just that. It will however, be very interesting to see if Apple brings extension support to Mobile Safari on iOS.

Coming back to Dion’s original post, it seems like we are closer to write-once, run-anywhere using client-centric web-based applications than we have ever been. With a few modifications, we can basically re-use 80% of our code to deploy on the desktop and mobile. Unfortunately, not all browsers are there yet though. The issues I listed above seem like minor ones that can be fixed easily however. It would not surprise me if in the second half of 2010, Mobile Safari fixes the refreshing issue and Android adds support for HTML5 Audio/Video. As more frameworks are released that deal with the fixed positioning problem, I expect more developers to look seriously at the web as their platform of choice for deploying mobile applications. As for the desktop, Firefox 4 and IE9 should finally add the HTML5 and CSS3 feature support that Chrome and Safari have had for a while now. Of course, not all users will have the latest and greatest browser. Progressive enhancement will be the only way to support those users. But by pushing the envelope of what’s possible, we will hopefully push those users towards upgrading to a modern browser.

For a 60 second run through of ExtensionFM, check out the video below:

Related Content:

  • What's in it for me?
    ASPs appear to offer cheaper applications and an end to your skills woes. But is this all too good to be true? Alison...

Posted by Dion Almaer at 6:07 am
12 Comments

+++--
3.7 rating from 13 votes

12 Comments »

Comments feed TrackBack URI

ExtensionFM looks very cool. I’m in mixed minds about not offering progressive enhancement, but I think it’s acceptable on bleeding-edge projects like this. And anything that encourages FF and IE to keep up with changes to the web (and that encourages users to leave IE6-7) must be a good thing.

Comment by Skilldrick — June 24, 2010

I think a good read here would be the classic: http://www.joelonsoftware.com/articles/fog0000000018.html

Perhaps this point might be made: if developers using html5, extensions, etc. only recreate existing user interfaces, software ideas, and so on, there has been something short of progress made. This is a music player. Is there a large market for those who have been *dying* to play mp3′s they find on webpages? When you think about that question, do you come up with other disruptive music distribution trends (and related lawsuits) which have occupied the popular consciousness since around the time Spolsky wrote his article? Can I type the name of a song and listen to it? HTML5 (only running in Chrome, no less) does not anesthetize consumer desire.

Comment by nataxia — June 24, 2010

Indeed, I agree with what nataxia just pointed out, emulating the desktop on the web is something short of progress. I have spent countless hours porting desktop applications to the web, but was it worth it?

Instead of just emulating the existing interfaces on to the web there should be an entirely new interface developed that puts the interests of the user first.

Comment by jhuni — June 24, 2010

Do either of you have a suggestion on how the UI for extension.fm could be improved? I tend to think about music in the form of a massive library, a queue or an unpredictable stream akin to radio programming.

I’m not sure a different UI would actually serve the music listener well…

Comment by j2d2 — June 24, 2010

I tried ExtensionFM and have to say I found it rather brilliant, the fact I’m a total music obsessive and spend a lot of my time crawling music blogs using hype machine (http://hypem.com) is definitely a factor. It enhances this experience so much that it might encourage me to move totally over to Chrome for my regular browsing, since I normally have some hype machine stuff going on in a background tab or two. Excellent job! :)

Comment by friendlyjs — June 25, 2010

@jhuni – I assume you’re being ironic as your link points to a web based emulation of the desktop… ;o)

I would say…

What’s the environment in which the application runs? Is it really a browser, or just another runtime in the OS? What’s the difference between a browser running a JavaScript App and a JRE running a Swing app (Swing is not native – it is another desktop emulation)? – Perhaps I’m being one of those “Architecture Astronauts”.

I think the line has (or more likely, always was) blurred for those who aren’t technology professionals. There’s not much difference between clicking on an icon to open a desktop application versus clicking on an icon that launches a browser and loads a web application. Do most users really care that there’s a distinction between a desktop app and a web app? I don’t think so, or are they really concerned with getting the job done quickly and efficiently (and hopefully enjoying the process)?

@nataxia – If you can’t be first to market, be the best. I’m sure the business owner(s) of ExtensionFM will have done market research into whether the product is viable or not and any legalities associated with that product space – if they haven’t then it will likely fail.

I would *guess* there is a market for this type of product/service as Marketing and PR companies are using blogs/websites to promote Artists and their music – (http://www.guardian.co.uk/music/2010/feb/11/google-deletes-music-blogs).

Comment by wukfit — June 25, 2010

@wukfit

I think that’s the point: do we really need another desktop emulation layer? Especially one that uses so much of your system resources before it even does anything useful.

On one hand, it’s pretty absurd that a simple document renderer has become this monster runtime. On the other, it does have an advantage over current technologies like Swing. Accessibility to developers. Which tends to be a bad thing (check out the source to any VB Script application…), but is also good in that the thing that is accessibility is not just “recreating that which already exists,” it’s the ability to create highly interactive things in a space where it’s currently difficult. And there’s this derogatory term, “programmer art.” But now all these great designers making these fantastic-looking-and-behaving things for the internet can possibly one day do the same for the desktop. Yet the overall perceived quality of desktop apps will most likely tank, because now all the worst programmers and non-programmers can make basic programs that use 80MB of ram and have a horrible user experience. Just as how everyone assumes that VB Script (or PHP, or JavaScript, or …) sucks because so many non-programmers use them, HTML5 on the desktop could end up being a tragedy of the commons.

Comment by adunn — June 25, 2010

@adunn I think its what this *new* desktop emulation layer brings – it lowers the bars so to speak, zero install, write-once-run-anywhere-almost… and there are always going to be good programmers and bad programmers, good designers and bad designers, good plumbers and bad plumbers, etc. In some cases this *new* desktop emulation layer is replacing the traditional one (ChromeOS, WebOS et al) and I suspect that this *new* desktop emulation layer consumes less resources than Windows 7 Ultimate for instance.

“On one hand, it’s pretty absurd that a simple document renderer has become this monster runtime. ” – and who would have thought we would have gone from this (http://dig.csail.mit.edu/2007/Talks/0508-query-log-privacy/phone-booth-red.jpg) to this (http://river.webblogg.se/images/2008/ericsson_hotline450combi_1206637992_860903.jpg) to this (http://cdn.mos.techradar.com//classifications/gadgets/phones/mobile-phones/iPhone/iphone4_2up_front_side-728-75.jpg)… ;o)… back when browsers were created thats all people needed/wanted…

Comment by wukfit — June 25, 2010

I agree, the better developers will create amazing applications with less effort with HTML/JS/CSS compared to traditional desktop programming. And no one will use something that sucks, so there’s that natural filter on quality.

“I suspect that this *new* desktop emulation layer consumes less resources than Windows 7 Ultimate for instance”

Sure, but windows is an entire OS. The windows GUI APIs definitely use very little resources compared to a full web renderer. But we’ll just through hardware at it and all will be well ;).

The run-anywhere aspect is probably the biggest and most exciting benefit. Part of the reason the web is now achieving what so many desktop languages and tool kits have failed to do so far is that the web has always been sandboxed. There’s little access to anything on the system that could cause cross-platform issues. It sounds like many of these interactions are being addressed with web workers, sockets, and local storage. And I think I heard some talk of using web sockets to interact with the file system. But there are still many (maybe edge-case for most people) interactions that won’t be possible. So there’s the question of where to draw the line on capabilities. For now that’s easy as web applications are zero install and shouldn’t have that much access to the system. As soon as they can be installed developers are going to try for more complicated interactions and will end up limiting compatibility. And that can be basic things, like relying on a certain windows command line utility to be present on the system. But of course it’s all about how you use your tools.

Comment by adunn — June 25, 2010

“The run-anywhere aspect is probably the biggest and most exciting benefit.” – which is a lie (like the cake), because of browser and platform differences. In this case the mobile safari reload bug (feature, depends on from where you look at it) is a total show stopper – but what about making these web apps behave “pretty similar” in the different desktop browsers? God damn hard to do so… and I haven’t even started on rendering or ecmascript implementation differences, or a client with an IE6 requirement – run-anywhere it is not at all. In the far future – maybe, but I doubt – but hell, maybe we’ll be able to run a music player with 512mb ram and then we can live happily ever after.

Comment by rosamez — June 29, 2010

@rosamez: use a toolkit that abstracts away the differences. ExtJS does a pretty good job on the desktop.

Comment by Joeri — June 29, 2010

@rosamez: ““The run-anywhere aspect is probably the biggest and most exciting benefit.” – which is a lie (like the cake),” – “or a client with an IE6 requirement”
Chrome (5??) is one of the “new desktop emulation layers” – IE6 is 10 years old…hardly new. Chrome, Firefox, Opera and IE and all starting to support new standard APIs/features that make these types of xbrowser apps possible… Workers, Video, Audio, File Access, Geolocation, Hardware accelerated GFX, DND, SVG.. etc etc…
“but what about making these web apps behave “pretty similar” in the different desktop browsers? God damn hard to do so… ” – no one said it as easy (“write-once-run-anywhere-**almost**”)- like Joeri said if you can’t/don’t want to write the code that handles any differences use a toolkit.

Comment by wukfit — June 30, 2010

Leave a comment

You must be logged in to post a comment.