I recently ran across a rather significant AJAX application. Perhaps “meta-application” is the better term. Ajax13, a company that has pushed the envelope with what is possible with Ajax and web-applications, has developed an Ajax-based desktop environment called ajaxWindows. There is a demo mode that is accessible and is worth checking out.
ajaxWindows provides a virtual desktop. Ajax13 describes it as a virtual operating system, as well as webOS, but I’m not sure I would agree with that description. From the point of view of needing to describe what it is to the general public, it is probably a reasonable moniker but it is rather misleading. An OS has so many more responsibilities than providing a user interface. It is missing many of the elements that make up an OS such as process/thread management, memory management and hardware management.
What I would call ajaxWindows is a framework. It enables (certain) web applications to work within its context. In addition to displaying the user interface in the virtual desktop, the application can access the virtual file manager to let the user organize and save files.
Whether you view ajaxWindows as an OS or a framework does not diminish it’s capabilities. For the most part, users will not be interested in anything more than being able to access and manage their space and applications from anywhere. And it is certainly an insanely extraordinary demonstration of what the web can be. Below I give some thoughts on the features and behavior of ajaxWindows.
What is most refreshing about ajaxWindows is that it permits interaction with the elements in a manner akin to native applications. That is, you have both a left and right mouse button. I have encountered a few web apps that do this (e.g., a number of Google’s apps handle the right mouse button) but most don’t. In ajaxWindows, the right button gives rise to context menus as you would expect. The usual web app ignores the right button which results it being handled by the browser. For me, that disconnect is seriously distracting.
The file system that ajaxWindows provides maps its physical storage to a Gmail account. If you sign up for an ajaxWindows account, you can use the application but in order to make use of the file system, you have to point it to a Gmail account. Once you do that the Synchronizer application on the virtual desktop will allow you to synchronize files on your physical machine with those in your Gmail space. While the synchronization is possible, I am not sure what that ultimately implies. It seems that the file system is potentially incomplete but I will address this more below.
The desktop itself comes with preloaded applications. Many of those the Ajax13 Office analogs as well as their MP3 manager. It also provides access to a variety of other web apps – like Google Docs, Google Calendar, Meebo, etc.
Though the desktop displays both the Ajax13 applications and the non-Ajax13 applications in the same way, there is a difference. Unlike the Ajax13 applications which “run” within the context of the desktop, launching the non-Ajax13 applications results in another browser window opening. For me, this was unexpected. In someways it makes sense – and works well if you happen to have a multi-monitor system. You can have both the browser instance that contains ajaxWindows (perhaps showing in full-screen mode) on one monitor and then have the browser instance containing the third-party application on the other. When both browser instances are displaying on one monitor, you get inconsistent behavior.
Suppose on a single monitor system, like a laptop, you open Google Docs. A new browser instance launches to display the application. It looks as though it is sitting on the ajaxWindows desktop but it really is a separate window relative to the host operation system. So, if you click on the desktop, or any of its contents, the Google Docs window disappears since the ajaxWindows window comes to the foreground. The task bar in ajaxWindows gives you an easy way to call it forward but this is not the behavior Ajax13 applications provide. They behave as expected within the ajaxWindows desk space.
The other disconnect between the third-party applications and the more resident ones is in how the file system works. Files created by the resident applications can store and retrieve files from the file system. Those created by the third-party applications don’t seem to share that option – even those created by Google.
I suppose this disconnect makes sense. On the real desktop, Google documents aren’t stored residently so accessing them is done through a browser. Even in the case of Google Gears, access to the files still looks like it is via a browser. Still, it seems an ideal way to go for a virtual desktop is to provide for virtual applications to appear resident.
Now, considering that it is possible to upload and store any file from the local file system, one question that arises is what happens when you try to open a file that is not supported by any of the applications known to ajaxWindows. In such a case, the unknown file is delegated to the local OS and you are prompted to open or save the file. The problem that arises is in trying to open files with extensions known to ajaxWindows with applications on the local machine. That doesn’t seem possible without first downloading the file. For instance, if I want to edit an XML file I am accessing through ajaxWindows, ajaxWindows will allow me to open it with it’s text editor but I can’t choose to open it with a non-ajaxWindows application like Google Docs, which is represented on the ajaxWindows desktop, nor an XML editor on my local machine.
This gives rise to what it means for an application to be “installed”. Without really understanding the inner workings of ajaxWindows (I couldn’t find an API and it probably isn’t going to be available for some time), my guess is that installation means that the application uses the Ajax libraries – or at least can be wrapped by them – provided by ajaxWindows. This would be the OS equivalent and would mean that the application would be able to run in a window on the virtual desktop. Third-party apps would still be delegated to separate browser instances running in the real OS.
From a platform perspective, Ajax13 states that ajaxWindows runs in recent versions of both Firefox (2.0+) and IE (6+). Firefox runs it inherently (no plug-ins needed). IE requires a plug-in available from Ajax13. There wasn’t any issues with running in either environment.
Performance-wise, I found ajaxWindows to be a little sluggish and clunky. While waiting a moment or two for an application to open and render a document’s contents was reasonable given what was happening, the real issue was with interacting with windows on the desktop. Motions had to be slow or unexpected results would occur – such as context menus appearing and the window moving chaotically around since the mouse never “dropped” the window.
Ultimately, I have to say that this is an amazing application. It’s very rich, very integrated – as much as it seems it can be at the moment, generally intuitive and very aesthetically pleasing. In the long run, many of the interaction and performance issues will be solved and improved and perhaps a smoother experience between the virtual and local systems will evolve.
What will be of significant interest is the opportunity for development. The most natural way to develop applications for an OS is to develop them in the OS. For example, to create Windows applications, you use Visual Studio and take advantage of the .NET libraries. Java development has a little more flexibility given its platform independence.
Once ajaxWindows provides (or provides for) a development environment (ajaxStudio? ajaxEclipse?), third-parties can create new web services that integrate right into the environment. We now have a commodity opportunity – and a platform independent one at that – which will create a rather interesting and robust market.
This is when enterprises will get interested. The utility of ajaxWindows at the moment is really just providing a common entry point for a collection of services. In fact, at the moment, it’s effectively a convenient organization of bookmarks and display of certain web applications with a common file system. While interesting, and certainly significant, the integration among the services is limited. But, enable the enterprise to create, or buy, the integration they need to provide remote access to their employees, customers or whatever, without concern for platform differences and in a way that still let’s them retain complete control? Now you’re on to something.
No comments:
Post a Comment