Multiple HTML Reply Signatures Remotely Served?

Ronald Heft of cavemonkey50.com made a comment here asking a question about how users could use their HTML signature when not at their own computer.

This question interests me because I believe that applications need to be accessible via the web. Many power users use more than one computer, and Firefox Extensions must correspond to a specific user profile.

There are ways around that within corporate networks. A Firefox Extension installed in a roaming profile will function for a user no matter what computer he or she uses, but a computer in the library or a coffee shop will effectively leave the user signatureless.

For my dual-boot setup, I could install my profile at a location on my FAT32 partition that is accessible by both operating systems. Then I could use the same centrally-configured Firefox Extensions, bookmarks, browser history, and other Firefox functionality from both Linux and Windows.

But suppose I'm sending an email from a friend's computer who is running Firefox, but who doesn't have my signature extension configured? Is there a way to serve this extension remotely? Applications such as the Mozilla Amazon Browser have made me very curious, and anyone who could implement something like this would surely differentiate themselves from the competition, as I'm not the only developer with a fancy HTML Signature extension.

As I mentioned in a previous post, I tried to manipulate the Google Docs interface so that I could use shortcut keys. Would it be possible to serve a XUL application that provided an interface to Gmail? Can another server -- perhaps one with the Greasemonkey engine installed -- effectively act as a middleman between a user and another server? Would security restrictions prevent this? Suppose I installed Firefox and the Plain Old Webserver on a remote server? Could I then serve my Firefox Extension remotely?

We will have to think about this concept for awhile...

Dynamic Remote XUL, Struts, and Java Server Pages

I've recently had the opportunity to use Mozilla's XML-based XUL user interface language for the frontend of an Apache Struts application. The idea consists of using Firefox tabs or XUL tabs to manage multiple windows in the application.

Is it a Browser or a Client-Side Application?

Essentially, the application will run in a Firefox browser; however, it will look like a client-side application. That is the beauty of XUL. Since the Firefox user interface was developed using XUL, applications written in XUL can "take over" the Firefox interface and integrate with it either partially or fully. Thus, the line between what components are Firefox and what components belong to the application is very thin.

The backend will be developed in Java and use Struts to help utilize a Model, View, Controller architectural pattern. We are breaking new ground here. Most Struts applications I've seen generate dynamic HTML, not XUL. The application will be served remotely, appear to be a client-side application, and use Struts Action classes as the controller.

Since Struts actions are called via url's, it's possible to have different parts of our application run in different Firefox tabs! Mozilla has an API that allows developers to interact with the browser. Using JavaScript, a developer can open a url in a new window, a new tab, or the current window. From a development perspective, this means we can force our different modules to run in different tabs. The application would essentially run not in one Firefox tab, but in multiple tabs.

XUL Tabbrowser

There's not a lot of information out there on Struts and XUL, but it appears to be a very scalable model in that the MVC framework means that even existing Struts applications could be retrofitted with XUL simply by modifying the view.

However, the lack of Mozilla documentation does present a challenge. I found information on the tabbrowser XUL element, but none of the information appeared to be correct. In addition, the Mozilla Developer Center API for tabbrowser was missing examples. After researching and testing a solution, I contributed the following example:




<vbox>
  <tabbox id="tabBrowser">
    <tabs>
    <tab label="Tab1"/>
    <tab label="Tab2"/>
    <tab label="Tab3"/>
   </tabs>
  <tabpanels width="500" height="500">
    <browser id="browserTab1" src="http://www.mozilla.org"/>
    <browser id="browserTab2"/>
    <browser id="browserTab3"/>
   </tabpanels>
  </tabbox>
  <hbox>
   <button id="btnLoadBrowserContent"
  label="Load URL"  oncommand="loadURL(document.getElementById('tab2'),'http://developer.mozilla.org')"/>
 </hbox>
</vbox>


The example above will display three tabs in a Firefox window. Each tab contains a browser object. Using XML DOM methods, the src attribute can be dynamically modified based on user or system events:

function loadURL(browserElem,pUrl) {
//modify the src attribute of the browser element
browserElem.setAttribute("src",pUrl);
}

The JavaScript code above will modify the src attribute of the second browser object and cause a page to be loaded in that tab. By replacing the src attribute with different Struts action urls, this application will be extremely dynamic and scalable.

Remote Applications and Operating Systems

There has been quite a bit of discussion centered around the use of the Mozilla-based XUL technology in order to create a rich user interface on top of a thin client. In the past two weeks, I've learned quite a bit more about the power of XUL, and I've gained more perspective as to where application development is heading in regards to Web applications, rich user interfaces, and operating systems.


Mozilla Amazon Browser

When I think of XUL, I think "Firefox Extension". I visualize browser overlays and add-in software that functions in conjunction with Mozilla Firefox. But yesterday, a co-worker introduced me to the Mozilla Amazon Browser, which renders rich web content through a Mozilla interface. This shattered my previous notions of XUL.



The Mozilla Amazon Browser looks and feels exactly like a client-side application, yet the entire application, including the user interface, is run from a remote server! In addition, the application can also be installed locally as a Firefox Extension with the same look and feel as the remote version! The only limitation is that Mozilla Firefox must be used in order to use the application; it won't run using other browsers, such as Internet Explorer.

This completely changed my view of what XUL is capable of! In 2004, Joel Spolsky of Joel on Software wrote an article about How Microsoft Lost the API War because of emerging Web development technologies. He described the user interface of Web-based applications as "a huge step backwards in daily usability". Because of this inability of Web tools to render a rich user interface to Web users, client-side applications will always have their place on the desktop. People like Mr. Spolsky and myself would much prefer to use a client-side interface that allows us to make full use of the keyboard to speedily control an application rather than stumble around the screen with a mouse pointer, reducing productivity and wasting time.

Technologies, such as XUL, that allow a Web application to look and feel like a rich client-side application and still allow users to access that content from anywhere have set the stage to replace client-side applications completely because they eliminate the user interface problem.


Client email vs. Web-based email

Many businesses are using Web-based email in place of using a mail client simply because email providers, such as Gmail, only provide POP access. The POP protocol only allows a user to download his or her email to one computer, so if employees within an organization use multiple computers this creates quite a challenge for using mail clients. Thus, as an employee working at such an organization, one loses much of the functionality that only the client can provide.

On the flipside, organizations whose employees use only one computer and do not rely on Web-based email, reap great benefits from the ability to perform certain actions, such as embedding signature images in emails. This is something that Mozilla Thunderbird can do in Gmail with POP access but something that the Gmail thin client cannot do without the help of a third-party Firefox Extension, such as Greasemonkey combined with the HTML Signatures for Gmail script.

What I see here in terms of client-side applications vs Web-based applications is a hierarchy of priorities which determine whether or not a user will use the client interface or the Web interface. If the user requires access from multiple locations then he or she must sacrifice user interface for mobility. However, if mobility is not necessary, then the user will be more likely to use a client-side application, especially if speed and the use of advanced features is required.

With XUL, developers now have the necessary tools to offer customers both mobility and a strong user interface. We can see this already just by testing Firefox Extensions, like Greasemonkey, to improve the features of Gmail.


Google Docs and Spreadsheets

Google Docs and Spreadsheets is yet another example of a Web application that offers users tremendous benefits in regards to mobility, yet still needs some work in terms of user interface. I am a big fan of this mobile Office suite because I can record information regardless of where I am or what operating system I am using. I even use the spreadsheet for complex tasks that would be much easier using Microsoft Excel or Open Office Calc, but mobility is ranked as a higher priority than user-interface, so I make do with Google Docs and Spreadsheets as-is.

However, in the last month I've been doing some experimenting of my own. I've been trying repeatedly, yet unsucessfully, to use XUL to interact with the File menu in Google Docs. As I previously stated, shortcut keys are important to me. When I press "Alt-F", I expect to see a drop-down appear with a list of File controls, such as "Save" or "Save As"; instead, My Firefox File menu expands. Reluctantly, I move my hand away from the keyboard to reach for the mouse, stumble around the screen while I point at Google's 'File' button, and perform a left-click.

One of the features of XUL is the ability to use the 'accesskey' attribute to allow users to use a shortcut key in place of a mouse click. My hope was that I could use this to call Google's ActionMenuLoader(fileMenuButton,'more') functionality from a local Firefox Extension.

Although my methods have not proved successful, I believe the secret to successfully implementing a richer Google Docs and Spreasheets interface can be found by studying the two Firefox Extensions mentioned earlier: Greasemonkey and the Mozilla Amazon Browser.

With Greasemonkey, local JavaScript code within a user's local Mozilla profile directory can manipulate browser content. Therefore, I wonder if it would be possible to add an HTML 'accesskey' attribute to Google's File button, allowing Google Docs and Spreadsheets to expand the File menu by using an "Alt-F". The advantage of this approach for someone like Google is that their application can still be accessed normally using a non-Mozilla browser yet still add this additional functionality to a Firefox user without making changes to existing code.

However, the Mozilla Amazon Browser has taken the user interface a step further by developing a user interface that interacts with remote content. It basically is remote content, depending on whether or not the user installs the Extension or accesses it remotely. I wonder if a similar interface could be developed for Google Docs and Spreadsheets to allow users the full functionality of a word processor and spreadsheet, minimizing the use of the mouse, yet still giving priority to those who require mobility.


Remote Operating Systems

Free Geek in Portland uses a technology called Lessdisks, which basically allows a computer terminal workstation to run an operating system from the server! In other words, the machine is essentially nothing more than a motherboard, a processor with RAM and other basic components, and a monitor. The machines they use do not have any disks. None whatsoever. They don't have a floppy drive, they don't have a hard drive, and they don't have CD-ROM drives.

If you logon to one of these Ubuntu Dapper 6.06 machines, it looks and feels as if you are running Ubuntu locally. I asked the head of Tech Support at Free Geek, Michael Westwind, if it were possible to run Lessdisks over the Internet. Although he seemed to feel that the system would be sluggish due to graphical delays as a result of slow communication, I totally see where we are heading. High-speed Internet may be too slow right now, but what about in the next few years? I can already successfully logon to my Windows machine through the Internet using Remote Desktop, and I experience very minimal graphical delays while productively working in this manner.



In fact, I'm writing this blog article using the CapOS Browser Operating System. This application allows the user to drag and drop windows within the browser! The browser window looks just like a desktop background, and I have windows that I can minimize, maximize, and close. I haven't had a chance to fully explore its feature-set yet, but this does hint that in the future all applications could be hosted in one location, be accessed anywhere, and have a rich client interface, possibly without the need for a local hard drive or operating system!

I think Microsoft is in trouble.

James Mortensen