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.”

RIA – Watered Down or Less Bloat

I just read Jeff Atwood’s Are Web Interfaces “Good Enough”? post. He explores why web (RIA) versions of desktop applications are “less satisfying” than the desktop versions. He makes some good points and I’d like to build on his post. I see it the other way around: Web versions have less bloat than desktop versions. Let’s state the obvious right up front: I am talking about good desktop and good web applications. You’ll find crappy versions of both.

Desktop applications have a tendency to go overboard with features and gold plating (bloatware) – trying to use every native UI widget/feature possible. They have to, because after the first or second version, the application has likely jumped the shark. The only way to keep people buying it is to upgrade the UI or add wizzy ways of executing commands (which already had a non-wizzy way). Desktop applications are released, deployed and installed less often. Deploying desktop software isn’t cheap.

Web applications have to work with less, which in most cases means the application has to focus on the problem at hand. Strong focus is a good thing. Web applications are cross platform and have a further reach than a desktop application. Web application are easier to upgrade and release.

What we are seeing today is a shift from desktop to web-based applications. For the majority of users (if your reading this, I am not talking about you) the ease and reach of a web-based applications is outweighing the lack of non-value add features. Even Jeff admits that he was able to do everything he needed with the web application. Do normal users have the “fit and finish” issues that developers have?

This trend will continue as browsers begin to enable more value add features, such as rendering, storage, and offline support. The trend is also why technologies like XULRunner and Apollo are interesting: Ways to create web-ish desktop applications.

Site Specific Browser – WebRunner

A few months ago, I posted about a concept called Site Specific Browsers (SSB). I didn’t invent the name or the concept, but I thought it was a great idea. An SSB is an application with an embedded browser designed to work exclusively with a single web application. It’s doesn’t have the menus, toolbars and accoutrement’s of a normal web browser. Some people have called it a “distraction free browser” because none of the typical browser chrome is used.

The recent talk/hype over desktop/web integration has rekindled my interest in creating a project to test SSB ideas. As is usually the case, I would not be the first:

Yeah, Google webapps are a popular choice for an SSB.

Looking at what has already been done and discussions about desktop/webapp integration, I am suggesting the following roadmap for SSB experimentation:

  • Separate process: When the webapp goes down or locks up, I don’t want anything else affected. Thankfully, Firefox does have session restore, but that is beside the point. When I open many tabs and have several webapps running in a browser, things get slow and unstable after a day or two.
  • Minimal UI: A generic browser UI is not needed for webapps. If any UI is present, make it specific to the webapp I am using.
  • Basic desktop integration: Create shortcuts to start the webapp, add ability to show specialized icons in the tray or dock and ability to display notifications.
  • Platform with extensions: I don’t want to download a full browser runtime for each webapp. I do want to be able to add some custom code/features that are not directly supported in the webapp. I should be able to install one runtime and then get packages or extensions for each webapp. Think Firefox extensions or Greasemonkey scripts. These extensions should be able to tweak the SSB UI as well.
  • Open external links in real browser: If I click a link in the webapp that opens a new site, don’t change my webapp browser window. Open all external links in my default/real browser.

XULRunner’s stable base, feature set and cross platform nature make it a good foundation to build an SSB. In fact, I’d just start with the the WebRunner prototype created by Benjamin Smedberg. Then, I’d turn on the Extension Manager support in XULRunner. Then, I’d create some extensions to “install” or “enhance” webapps. Then, I’d add some patches to add better desktop integration (I’m hoping the patches land for Gecko 1.9). Then, … well you tell me! How about offline mode? What else?

Here is a simple example of a WebRunner-based SSB. It only begins to cover the points on the roadmap, but it is a start. The application is designed to take a -uri parameter on the commandline. The installer will setup desktop shortcuts to launch webrunner.exe with specific URIs for Google web apps. The UI is minimal, just a simple statusbar to show load progress.

Install (Windows-only): webrunner-setup-0.2.exe
Source: webrunner-src-0.2.zip