Posted on

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…

Posted on

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.

Posted on

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

Posted on

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.

Posted on

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 link) to an SVG resource.

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

Posted on

Site Specific Browers

Recent posts from Zach Lipton and Robert O’Callahan share a common theme: Give web applications better integration into the desktop.

I have a strong interest in this area myself. A while ago I came across a desktop application for the Mac called Pryo. It’s an application with an embedded browser designed to work exclusively with a single web application: Campfire (a web-based IM service from 37Signals). Pryo allows for many things that are either difficult or impossible for Campfire to do on its own. The guys behind Pryo call it a Site Specific Browser. There is even a Windows clone in the works.

Zach provides a simple proposal for “appifying” Firefox for specific sites. I am wondering if a Firefox extension couldn’t be used to test out some of these features. Instead of a tag, I was thinking of a to some sort of manifest file. The manifest could specify how to modify the Firefox UI to be more site specific as well as setup desktop shortcuts. Of course, the user should be in full control of allowing any of this to happen. Preferences would control a site’s ability to “appify” itself and the user should be able to revert back to the “non-appified” version of the site.

Site specific browsers could be the Next Big Thing with Ajax applications appearing faster than rabbits. Seems like TechCrunch has 2 or 3 new web applications popping up everyday. Better desktop integration would definitely enhance the user experience.

Posted on

I am My Data, My Data is Me

I couldn’t help but get caught up in the recent threads about data lock-in. I have become quite a “data-snob” recently which, I’m finding, is quite abnormal for a developer. Developers are all about the code. On one side you have the Mark Pilgrim & Jon Gruber (& Mark’s reply) discussing Apple’s data lock-in problems. On the other side you have Stewart Butterfield’s not-so-positive comments about allowing Flickr to export to Zooomr or Google’s new online Photo Ablums.

Lots of people are making the connection that these different threads have much in common: People use software to store important data; The data belongs to the people, not the software. This is not about Mac vs. Ubuntu or Flickr vs. Google. It’s about users feeling secure that their data won’t rot away in some application’s proprietary file format.

Is it any wonder that people are more at ease storing photographs in a shoebox than on a computer? It’s easy to take the photos out of the shoebox and move them to a photo album, or to a picture frame. How easy it is to move your photos and metadata to newer software? Or your letters, or your finanical information, or your tax returns?

Things are getting better. Microformats, Atom, and a desire for applications (specifically web applications) to interoperate is raising the bar. Even Microsoft Office finally has a relatively open format with full fidelity. Full fidelity is important or else you’ll lose data when you try to convert to another format. Software developers need to realize that the data will live longer than the software and there should be a simple, easy way to access the data without the software. Until then, your data may not be safe.

Posted on

OO Design, Hobgoblins and Foolish Consistency

I started using C++ over 15 years ago. I still use it every day on the job. I have picked up some other OO languages along the way as well. When I learned OO principles, there was a quote I heard often:

When an OO problem looks too difficult, add more objects.

It usually worked, but price was complexity. Simplification by adding complexity. After years of maintaining my own code, as well as other’s, I no longer believe in the philosophy of the quote. My current philosophy fits better with:

When an OO problem looks too difficult, stop using OO.

This works really well, I just had to stop feeling guilty about losing faith in OO. Nowadays I am a mentor to younger developers (for better or worse) and one of my big challenges is getting them to understand why foolish consistency to OO is a problem, not a solution. Over engineering is a real problem (not just with OO). I attribute much of my change to:

  • Using Agile processes that force me to ask “Am I going to need it?”. If I am not going to need it, why am I coding it?
  • Working with dynamic languages to get side projects completed quickly. What if all my projects worked as well as my side projects?
  • Realizing that code is just a means to provide value to a user. The user wants the value, not the code.
  • Discovering that code is suppose to be temporary, it’s the data that lives on. The code you wrote yesterday sucks, and it always will.
  • Understanding that simpler does not mean not as good. It never means complicated, but it can sometimes mean elegant or even robust.

If you think it’s hard to get young developers to understand these ideas imagine how hard it is to get experienced developers to accept them. There are signs all over the place, you just need to look for them.

Posted on

UI Frameworks Are Pigs

Why are UI frameworks pigs? Because they don’t love you back.

You know the story: You meet this new UI framework. It seems so fresh and exciting. You start spending more time together, just doing small stuff. Things are so easy, not forced or boring like with your previous frameworks. So what if it acts a little immature. Before you know it, you’re writing specialized controls from scratch, embedding large amounts of business logic and enjoying every minute of it. You’re head over heels. Next thing you know, you’re crying yourself to sleep and listening to Barry Manilow.

Come on buddy! Snap out of it. UI frameworks don’t love you back. They don’t care about you. You need to watch out for yourself. Protect yourself. Isolate your code.

If your not ready to drop your current UI framework and switch to something else right now because it could take person-years to port, you have problems. If you have team members that love your current UI framework too much to want to change, you have problems.

They don’t love you back.

The experiences above are not about me, but I have this friend…

Posted on

OOD – Less Is More

My primary professional development language has been C++ for as long as I remember. It still is and I have no strong desire to move to something else. That also means that, many years ago, I embraced the Object Oriented Design (OOD) methodology.

I have derived Cat and Dog from Animal many times. At first, it took a while to see the object hierarchies, but it became easier. I loved object hierarchies. The deeper, the better.

Then, I started COM programming and designing using interfaces (abstract base classes) seemed to free my mind of the implementation details. I was happy. I was using interfaces for non-COM code in no time.

Then, I started using templates. First, with the help of the STL. What a concept! Later, with the help of Modern C++ Design (Andrei Alexandrescu) and the Boost libraries. Implementing design patterns using templates was amazing. Templates allowed me to do things I thought only inheritance could. I am glad I was wrong. Suddenly, my object hierarchies are not as deep.

Then, I started to learn XML and Services. Not really programming, I know, but the concept of storing all that data in a document that could be queried so easily made me question all those class getters and setters. Even some kinds of inheritance seemed overkill. Why can’t classes be more behavorial and less stateful? Let XML be the state and just pass it around.

In the end, I’m still using objects. Just less of them. I guess the data is becoming more important than the code.