Bubblemark is an RIA Benchmark?

The Adobe RIA crowd have been causing some echos in the chamber lately over Bubblemark, an animation benchmark originally released over a year ago. Personally, I have no real skin in the game, but a game it is. Some Flash developers were curious about variations in the results when run on different browsers, platforms and in the AIR runtime. It makes for some interesting reading and I came away with a better understanding the variations, browser limitations and timer mechanisms.

What caused me to gush milk out my nose was reading that this benchmark appears to be some kind of de facto standard for RIAs. No way! Someone is going to have to explain, speaking slowly and using big letters, to me how rendering an bunch of bouncing balls and calculating a framerate from the bouncing balls is a benchmark for RIAs. I guess if your RIA is an animation of bouncing balls (or non-balls too, I guess), this test has you covered. Thankfully, I’m not the only one. The Flash guys have more than a few gripes with the test. Sean Christmann sums up my biggest gripe:

The test just moves balls around! This is my biggest beef with the benchmark because it only tests one simple aspect of the rendering engine in these technologies, which is bitmap translation. How do bitmaps moving around the screen tell you anything about the capabilities of the respective technologies? Do the JavaFX guys really think optimizing this usecase will make their technology relevant? The only thing Bubblemark will tell you is which runtimes might best handle bitmap particle emitters….thats about it.

Instead, I’ll offer that the Bubblemark test has value in that many different technologies have implemented the test. Therefore, it provides some level of benchmark for how different technologies can be optimized to implement the test. Of course, I could be way off base here and the RIA of which they speak is actually “Really Interesting Animations.” If so, whoops, my bad.

I Call Shenanigans!

Zoho’s recent blog post about why they used JavaScript and not Flash when building their offline version of Zoho Writer has led to some interesting but somewhat predictable responses [1] & [2]. I could have fallen into a predictable (but not necessarily interesting) response myself, but didn’t. Until I saw Ryan Stewart post the following:

I don’t think it’s an accident that Zoho and Buzzword have such different design goals or that Flex applications generally tend to look more sophisticated than Ajax applications.

That quote (and the post) seem to suggest that AJAX webapps are less usable, less sophisticated and, generally, not as pretty as their Flex counterparts. Likely not Ryan’s intent and I did say “seem to suggest” right? I usually don’t define usability based on how an application looks, but on how productive I am using the application or how easy I can learn the application. Unfortunately, some applications try to get by on looks alone. I try to see the inner beauty.

Of RIA, Open Web and Plugins

Adobe’s Ryan Stewart has a post on the friction between Open Web advocates and “RIA vendors”. I think Ryan does a good job describing the work being done at Adobe (and Microsoft) to become active in a larger ecosystem, namely open source and cross-platform. There are a couple bits I want to respond (emphasis mine):

I think it’s indicative of wider problems between the “open web” and RIA vendors. The basic issue is that everyone’s too combative. I wish more open web people would look at what both Microsoft and Adobe are doing and see that all in all, the RIA solutions are becoming more open, not less. In fact, I’d argue that RIAs have moved the entire web in a more open direction.

I think Ryan’s use of the term “RIA” to indicate a “proprietary vendor plugin” will cause confusion. Rich Internet Applications can be created without the need for proprietary vendor plugins. Also, what Adobe has done around open sourcing parts of their plugin system has been welcomed by everyone. However, there are still large chunks of closed source and encumbered file formats that work against the Open Web.

I’m not sure if RIAs will ever be as fully open as the open web advocates want, but think how far applications in the browser have come (as far as openness) since the days of ActiveX enhancements in IE.

As I have stated, RIAs can be fully open and, as a card carrying Open Web advocate, those make me happy. However, how far have Adobe and Microsoft come from the days of ActiveX vendor plugins? Last time I checked, ActiveX was still the technology of choice for Flash and Silverlight on IE. Honestly, even if Flash and Silverlight were completely open source, the fact they are plugins and not native Web standards will be a stumbling block for many Open Web folks.

They’ve [Flash and Silverlight] pushed the web forward in a way that it seemed the open web groups couldn’t (video, vector graphics, easy cross platform/browser development).

Yes, they have pushed the Web forward, I’ll admit that. The resurgence of SVG and the new <video> & <audio> elements are evidence of that. But then Linux is a platform too, and I suppose that Mozilla could market Firefox as the one, true cross platform Web platform – but we don’t. We encourage choice and competition. We want developers to have choice too and not be locked into a single stack. Let me know when Flash can run a Silverlight application.

Mike Shaver responds in a comment to the post.

Joel Spolsky and Weak Metaphors

Joel’s latest strategy letter is a long-winded diatribe on the current state of browser-based application development. There is some good stuff in there, but some of the metaphors are really stretched and the comparisons between desktop and web-based applications is a bit broken. Joel seems to think that web-based applications should support the same kind of features as desktop applications. This line of thought can only go so far.

For example, cut and paste between applications. I assume Joel wants to copy more than text from edit boxes and selected HTML from the page. No reason this couldn’t be done today (Live Clipboard anyone?) but doing so requires cooperation between the applications in question. The Web platform already supports it. And hey, the same kind of limits occur on desktop applications. Try pasting an Outlook contact into Quicken. On the Web right now, microformats and mashups provide functionality not easily possible in desktop applications.

Joel also brings up lack of UI consistency in web applications. Not so sure about this one. I believe a little bit of consistency goes a long way and many web applications share common UI elements and concepts. Let’s not forget just how consistent desktop applications can be. Microsoft Office seems somewhat consistent with its applications, except for the ribbon is missing from some. Sure, it may not be appropriate in all applications. I’m fine with that – just not overly consistent. And take a look at the UI’s of “web-style” desktop applications and media players and tools like Microsoft Expression (best if viewed with Silverlight). Again, just saying a little consistency goes a long way.

Finally, we get to the “NewSDK” concept. The super-do-it-all framework that all web applications use and Joel compares this to Microsoft Windows and the Windows SDK. Personally, I would be comparing the Web to Windows, not some framework that runs on the Web. Compare that “NewSDK” framework to MFC or WPF. In a followup post, Joel responds to readers who forwarded their version of the “NewSDK” by saying:

Indeed countless people have already emailed me to say that “NewSDK is here, it’s (choose one) Flex Builder, Google Web Toolkit, Java Web Start, Silverlight, JavaFX, Flash, ActionScript, MORFIK, OpenLaszlo, … (many omitted)” Ahem. These are not HERE until your TAXI DRIVER has heard of them, because I assure you he’s heard of Microsoft Windows.

Again, he’s comparing apples to oranges. Ask your TAXI DRVIER if he’s heard of the Internet. And again, I’d use MFC, WinForms, VCL as desktop examples of the “NewSDK” examples listed in the quote. Ask him if he’s heard of WPF.

Here’s another quote that rubbed me the wrong way:

If you’re a web app developer, and you don’t want to support the SDK everybody else is supporting, you’ll increasingly find that people won’t use your web app, because it doesn’t, you know, cut and paste and support address book synchronization and whatever weird new interop features we’ll want in 2010.

The ideas in this quote are exactly NOT what the Web is about. This is anti-Web. Forcing interop by mandating a framework is ridiculous in a place where open standards and formats are embraced. Web development can and is improving, but let’s not try to turn the Web into Windows. Of course, some people already are.

If By ‘Web-Enable’ You Mean ‘Desktop-Enable’, Then Yes

Ryan Stewart has made a critical blunder in his attempt to create a Kawasaki-esque mantra for Adobe STEAM. This blunder will likely cause the failure of Adobe MIST and the eventual collapse of Adobe itself. I give you Stewart’s mantra:

Web-Enabled Desktop Development

Clearly, the man has lost his senses. Such bright promise – a pity really. Web enabling a desktop application is like embedding MSHTML in your MFC application and if this is Mr. Stewart’s vision of the future, perhaps they need to keep some windows open on the bus. I have been working tirelessly (not really) on a concept called WebRunner – similar to Adobe WIND, only better – and have also created a mantra:

Desktop-Enabled Web Development

The countless hours spent on my mantra were worth it and the distinction is so obvious even Google Translate could see it. Yes, ‘Web’ is the focus here – ‘Desktop’ is dead. Mr. Stewart is no doubt kicking himself over this whole incident. To show my empathy, I am allowing Mr. Stewart to use my mantra in place of his own (CC BY-ND).


Of Communities and Interface Friction

Dave Humphrey’s latest post really got me thinking about a couple things. First, I think what he proposes is a timely, interesting idea. It illustrates the power of the web brought to bear on a particular problem. Specifically, the post got me thinking about building communities and lowering interface friction placed on users. Not exactly peanut butter and chocolate, but I think they are related none the less.

Dave’s idea (read his post for the full details) develops as a reaction to someone else’s solution to a problem:

How can information (medical information, in this case) be vetted or deemed trustworthy by a knowledgeable community (medical professionals)? How can that trust data be used by others looking for reliable information?

The initial solution was to create a web application that contained the details and notes on web pages that were vetted. Users could log into the system and search for trustworthiness level of a given web page. Other users could log into the system and set the trustworthiness level of a given web page.

On the surface, it would seem that a community is being created around the medical information web application. If the service was useful enough to get users to accept the friction of logging into a web application to search or perform data entry, then the community would grow and sustain itself.

However, I doubt that would happen. The many steps needed to reach a result or enter data would turn away most people. We can certainly do better than that and, in fact, have done better. Though unrelated, I could use subscribing to RSS/ATOM feeds as an example. When I find an interesting feed (through normal browsing behavior), I subscribe to the feed from my browser chrome (one way or another). I don’t launch my feed aggregator and manually add the feed. Very soon, browsers will do the same thing for lots of types of information (can you say microformats? yeah, you in the back).

Any usablility guru (and even some normal folk) will tell you that interrupting the user’s flow is a bad thing. Instead of forcing the user into your conceptual model, try working within theirs. In Firefox, you can look at extensions like Operator, Fleck, The Coop and Joey to see where the trend is headed. Heck, Flock is built on the concept. Allowing the user to contribute or share while performing normal browsing, with as few steps as possible, will maximize the value of the community.

Creating an extension that overlays the medical meta-data into the current web page really lowers the friction for users looking for trustworthy data. Allowing the user to “markup” or “annotate” the current web page information really lowers the friction for users assigning trustworthiness to a web page. People who need to determine data trustworthiness can do so with zero effort. People who supply the trustworthiness can do so with minimal effort, so there is more, current trustworthiness data in the system. One side feeds the other to the benefit of both. Just imagine if everyday folk could use such an extension to look for reliable information on the web.

Another reason I like Dave’s idea is a bit selfish. I am not a Facebook guy and I don’t “do” a lot of the “social for the sake of social” stuff (see Twitter et al). But here is a real, social, community (albeit niche) that provides something more than social value. I guess that means I should offer services to make this become a reality. I can only look at pictures of cute cats with witty captions for so long. Dave, what’s your plan?

Inner Beauty

Ryan Stewart, new Adobe evangelist (sweet), is looking for sexy AJAX applications. You know, the ones that look like Flash:

So where are other sexy Ajax applications? I’m not talking about Gmail or even Google Calendar, I’m talking about applications you could mistake for Flash, the kinds of applications even *I* can’t help but admire (even if they could be built faster with Flash and Flex 😉 ).

What’s the point? Ryan, we all know that beauty is on the inside. The only time Flash impresses me is when someone uses it in an invisible way. sIFR, Google Finance & dojo Storage come to mind.

If we want to point to successful AJAX applications, why exclude GMail, Google Calendar, Zimbra, and Highrise?

Confucius says – Everything has its beauty, but not everyone sees it.

Much Ado about XULRunner

Yes, there has been a lot of talk about the Mozilla platform lately. This is to be expected considering the hype generated around Sliverlight and Apollo platforms. Most of the discussion is coming from well meaning developers, using (or trying to use) the Mozilla platform to build products. Developers who want to see the open Mozilla platform flourish in the face of closed competitors. I have a special interest in the platform too, its how I ended up working at Mozilla, so I also want to see it succeed.

Yes, Mozilla made an official announcement (Mitchell’s pre-announcement, Shaver’s preemptive-response) about the plan for XULRunner, a physical manifestation of the Mozilla platform. The announcement contains a lot of information and covers many aspects of the Mozilla platform. Mitchell discusses how the platform will be used internally, to how Mozilla will respond to the platform runtimes from Microsoft and Adobe, and everything in-between. The plan specifically covers:

  1. XUL as Language
  2. XULRunner to Support Firefox and Browsing
  3. XULRunner to Support Other Applications
  4. Stand-Alone XULRunner

Yes, there have been a few “sky is falling” responses to the official announcement. It’s my opinion that the responses have been focused too much on one item in the announcement:

The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2.

This quote is part of the Stand-Alone XULRunner plan (#4). The news that Mozilla will not be packaging a system-level version of XULRunner is disappointing to some people. I, too, would like to see such a product, but I think people are severely underestimating the amount of work required to make it happen. A shared, system-level component is not an easy thing to do. When multiple applications share a runtime, versioning and upgrading needs to work almost magically, or some applications will break.

Personally, I am far more interested in the first 3 points. There is some really positive information in the other points:

  • Mozilla will continue to invest in XUL. Just look at the XUL section on the Firefox 3 for Developers page. Development focus is primarily on the needs of Firefox, but should also address broader needs (“Specific examples of how this works in practice have been the inclusion of thread-safety patches and graphics patches beyond Firefox requirements …”)
  • Mozilla will continue to develop XULRunner as a platform for delivering Firefox. Anyone tracking the Mozilla 2 development knows that Firefox and XULRunner will be the primary projects. Just because Firefox will not be delivered with a shared, system-level XULRunner does not mean Firefox will not be built on XULRunner.
  • Mozilla will work with XUL application developers to help move the XULRunner platform forward. This includes working on features and bugs that no only add value to Firefox (and Mozilla projects) but also external projects. Downloadable builds of XULRunner will still be available.

XULRunner is not dead. Do not believe words to the contrary. Its time the XULRunner community begins to focus its efforts to move the platform forward and provide less negative, stop energy.

You Are Mozilla – Yes, You!

From Mike Shaver (back after a *cough* hiatus):

…if you’re on the web, and you care about the web, and you’re afraid that we might yet again have a monoculture of stagnation on the Internet, you’re “Mozilla” — even if you don’t know it yet.

He had me at “ever-declining respect for personal hygiene.”