Archive for Rants

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


Comments (2)

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?

Comments off

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.

Comments (5)

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.

Comments (14)

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

Comments (2)

Because Choices Are Good, Right?

From Dare Obasanjo:

It looks like Web developers are getting spoiled for choice this summer; Sun vs. Microsoft vs. Adobe vs. Web Standards.

Good times, good times.

Oh, if only tech hype could counteract the effects of global warming…

Comments (3)

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.

Comments (5)

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

Comments (12)

Apollo and RIA Thoughts

Rich Internet Applications (RIA)! It’s still a hot topic. Last time, the hype was for Microsoft’s WPF/E platform. This time it’s Adobe’s Apollo platform. Due to be released sometime before mid 2007, Apollo is a neat platform built on Flash, Flex and Webkit. Adobe recently had an invite-only event, Engage, to show off the platform and demo some applications. It created quite a bit of blogbuzz.

I am not really convinced that Apollo will be the next big thing, but I could be wrong. There are some aspects of Apollo, WPF/E (or any runtime wannabe) that cause me to stop and think before falling head-over-heels.

  • Platform vendor lock-in: Vendor lock-in is not a black/white issue. Some form of lock-in is always present. It’s more of a sliding scale. Tight lock-in (think MFC/COM apps) to Light lock-in (think cross-browser DHTML).
  • Platform openness: Can you fork or hack the system? Can you supply bug fixes?
  • Ability to extend with native code: You’ll likely need a feature not supported by the platform. Can you create an extension or plugin? Can you interact with the native OS or 3rd party databases?
  • Interaction with desktop: Blending into the native OS is important to user experience.

Of course, the Mozillian that I am, I can’t help but think of XULRunner… Hmmm

Update: Ted Leung and Anne Zelenka have some “stop and think” posts too. I agree a lot with Ted. The day I stopped sharecropping for Microsoft was fantastic.

Comments (3)

Mozilla ActiveX Control

I was a little surprised how “popular” my XUL/E post became. The demo viewer page alone has over double the hits of the second place page. In that post, I demonstrated how Mozilla’s rendering engine (Gecko) could be embedded in Internet Explorer and used to display rich XUL applications and advanced SVG and canvas graphics. Of course, XUL/E is a play on Microsoft’s brand-new-fantastic-sliced-bread WPF/E technology and Mozilla is not mounting a XUL/E initiative (but I can dare to dream).

However, the Mozilla ActiveX control is real and is a quick and easy way to embed a Mozilla web browser not only in Internet Explorer, but any development environment that supports ActiveX controls, including .NET WinForms. Adam Lock’s pages have a lot of information on the control. If you want a current build of the control, download XULRunner, as the control is distributed in that package.

In the comments of my XUL/E post, some asked about using the control as an alternative to Adobe’s SVG ActiveX control. This is certainly possible, but not ideal in it’s current form. However, some small changes could make it much more feasible. One change would be making the control a default viewer for the SVG MIME type. Doing so would allow the control to automatically display SVG whenever IE navigated (directly or by <A> link) to an SVG resource.

I already have a patch to do that exact thing for the XUL MIME type.

Comments (2)

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »