Revolutionary Testing Tools for AJAX Applications

Revolutionary Testing Tools for AJAX Applications

http://blog.browsermob.com/2008/12/faq-how-do-you-compare-to-selenium/

A few years ago, we used JMeter to try and load test a chat application we were building. Since the chat application used Comet and AJAX, I knew that the JMeter test was going to be grossly inaccurate. However, we did the best we could with tools that clearly weren't right for the job, as nothing was out there that could simulate an AJAX or Comet load test.

A few weeks ago, while working with some other consultants on a project, we discussed the use of Selenium to run some functional testing on a Firefox Extension that inserts signatures into an email. We needed a tool that could automatically send an email using Gmail, Yahoo, and Hotmail, and verify that the signature was still injecting. From my days writing HTML Reply Signatures for Gmail, I knew that this was indeed important, as any change by these third parties could have a drastic effect on the tool's ability to insert a signature.

Today, one consultant and I worked to try to insert an email address into the "To" field of the Gmail Compose window using Selenium. I've done this already in the Firefox extension, and anyone who has ever written a Greasemonkey script or Firefox extension that works with Gmail 2 can attest that this is not always an easy task if you are working outside of the API exposed by Gmail. Google engineers have put lots of effort in writing server-side code that ensures that all the id attributes in the Gmail application randomly change each session. Their creativity has sparked our creativity, and we have solved this problem. With enough time and patience, any problem can be solved.

Anyway, with Selenium, one must locate elements in the HTML of a web application by using XPATH queries. Armed with my trusty Firebug tool, I inspected the element in question and worked my way up the tree one element at a time, writing down the element tag names and positions at each step. Like a complex code, we ended up with long XPATH queries, a seemingly endless series of div[1]/div[2]/div[1]/div[1]. Although I would have preferred to just use JavaScript and a good for loop or regular expression to locate what I wanted, being a code cracker and approaching this problem from another angle was an eye-opener, XPATH is perhaps the way to go!

So that's a little background on my experience so far with testing tools. Selenium isn't a load testing tool of course, but it's a great tool to automate functional testing. It's almost like a macro recorder, similar to iMacros. Our plan is to set our test up on a VMWare image and configure this to run automatically every day. We'll get emails with our signature if it's successful, and broken or no email if it's not successful. We're also configuring it to be really loud and obnoxious if it does detect that something is amiss, just so we don't gloss over the automated emails.

Selenium can do functional testing, but what about load testing? Sure, Selenium can do load testing as well! Selenium uses real web browsers in testing, but it's up to the person doing the tests to go out and purchase the hardware to run the tests. In other words, if you want to do a 100 user load test with Selenium, you need to have 100 computers in your lab and 100 people to all click "Run" at the same time.

This is analogous to a symphony with you as the conductor who tells everyone exactly when to click "Run Test".

Of course, coordinating such an event can be costly, so one of the developers of Selenium Remote Control founded BrowserMob. BrowserMob solves this issue by providing the hardware. They claim to load test your web application using Selenium scripts and N number of real web browsers! I would be really interested to know how this was accomplished and how the costs have been kept so low.

To start, they probably use VMWare and Linux, which is one way to reduce the amount of physical hardware while still trying to simulate real hardware. They say they use Firefox 3.0, which is available on Linux. Finally, if Selenium Remote Control launches Firefox browsers to simulate functional tests, then my guess is BrowserMob is controlling a series of Selenium Remote Control instances, all running on VMWare Linux machines, and allowing BrowserMob to monitor the load.

While there are some costs associated with BrowserMob, I imagine one could use Selenium Remote Control installed on several VMWare images to run a small load test. If anyone has experience with either Selenium Remote Control or BrowserMob, I'd love to hear your thoughts on the two products!

HTML Multiple Reply Signatures for Gmail 1.0.2.3

Don't get too excited. The Multiple HTML Reply Signatures Extension 1.0.2.3 update doesn't include too many new features. I got rid of the red update link that appears in the toolbar. I don't think it was working correctly. In addition, it took up valuable browser real estate. Bad idea.

I did try to see what would happen in Firefox 3. Sadly, the Firefox Extension doesn't work in Mozilla's newest and fastest browser. The problem isn't the editor or even the signature injection. It's the module that reads data from the XML file. This was a hack anyway. I could probably get by with using the Firefox RDF API or perhaps store the signatures using the preferences system.

The good news is, converting to Firefox 3 wouldn't be hard. The bad news is that I don't have time to do it. We just need to fix the mechanism that reads signatures from the XML data file! That's it! Everything else appeared to work when I tested it!

Anyone know any JavaScript who is bored? HTML Multiple Reply Signatures for Gmail is licensed under the GPL! You can crack open the XPI and try to fix this yourself! I'll even tell you what files to modify if you email me!

I did start working on a version for Gmail 2. Interestingly enough, there aren't many solutions out there for Gmail 2, yet there was tons of competition for Gmail 1. I have a prototype that Susan Hemmersmeier has happily tested for me. It's very buggy though. Too buggy to put up on the blog, and too buggy for her to use.

Susan asked me when this will be finished. I hate to keep promising that "I'll eventually get to it.". You see, thanks to this blog, I landed some contract work! It's a lot of fun, but it takes up a lot of time. As a result, it would appear that HTML Multiple Reply Signatures for Gmail may be a (sniff...) dying project...

Do you have the skills to resurrect it from it's ashes? Let me know! I can definitely provide the moral support and answer technical questions, I just can't devote programming time to it at the moment.


James

Open Source JavaScript Compressor

Are you concerned about having your Firefox Extension JavaScript code compromised? XPI files can be extracted and code can be easily viewed. One solution that works very well for many organizations that wish to keep their JavaScript code secret is to use a JavaScript obfuscator.

Also known as a script compiler or script compressor, an obfuscator takes human-readable JavaScript code and converts it into text that is virtually impossible for humans to process. When you're ready to deploy your product live, your developers can "obfuscate" a version of the code for distribution and maintain the original human-readable version for continued maintenance and development.

In addition to making it difficult to reverse-engineer, compressed JavaScript files are generally 40% to 60% smaller than their aesthetically pleasing human-readable counterparts, as a result of comment, whitespace, and line break removal.

http://www.javascript-source.com/

Please see the above link for a quick example of the difference between a human-readable JavaScript function and an obfucscated function. I wouldn't recommend purchasing this version though as there are open source versions out there that will accomplish the same goal.

http://javascriptcompressor.com/

This version is Dean Edward's Packer. The problem with this is that the website has a decoder. This kind of defeats the purpose of obfuscation, and I would recommend it only for compression and not obfuscation.

These tools appear to be a great way to keep proprietary JavaScript code from falling into the wrong hands. Obfuscation is not prefect or foolproof, but consider this question: Is a thief more likely to snoop around in a car with unlocked doors or one that is securely locked?

Here are some links to free or open source obfuscators. All three work from the command line:

- YUI Compressor
- ObfuscateJS JavaScript Obfuscator
- JSO (JavaScript Obfuscator)

Multiple HTML Reply Signatures for Google Apps

Gmail HTML Reply Signatures Greasemonkey Script

The company I work for uses Gmail for email communications. Specifically, the service the company uses is part of the Google Apps bundle of services, and it's the same service that I use for my blog email.

As many of you may know, custom signatures through Gmail can't contain HTML by default. However, HTML Multiple Reply Signatures for Gmail solves this by using the Greasemonkey engine to inject HTML into the page. The HTML Multiple Reply Signatures Script (and Firefox Extension) injects a drop down list to the left of the Gmail editor where a user can select from up to four customized HTML signatures, which will be injected into the Gmail editor.

History of Gmail HTML Multiple Reply Signatures

About a year ago, I integrated the HTML Reply Signatures script into our company's global Windows profile. Since the global profile was shared across most of the company workstations, I created a DOS batch script that took the user's Windows login details from a workstation PC and generated the Greasemonkey script using this information. The generated script on each workstation is exactly the same, except for the filename of the signature image to use. The constraint is that all of the images must use a standard naming convention and all be located on the same public server.

Reliable Gmail HTML Signatures Solution

This solution has worked out quite well. It has been very stable and reliable in the last year and has required absolutely zero maintenance. Now that we have a need for certain people to have more than one signature card, I suggested that one of our managers install the HTML Multiple Reply Signatures Greasemonkey script. So far, he's pretty satisfied with it.

Not being on the global profile made this much easier; otherwise, I would need to write a new batch script that generates the HTML Multiple Reply signatures script instead of the HTML Reply Signatures script, which can only handle injecting one signature. In addition, not being on the global profile means that he could essentially name the image files whatever he wants, as long as he modifies the signature HTML in the script to point to the correct filenames.

I recommended the script instead of the Firefox Extension for three reasons:

• The script is actually more reliable and bug-free than the Firefox Extension.


• This particular manager is technically adept and fully capable of modifying the script himself to configure new signatures.


• Google Apps Gmail is not using Gmail's New Interface, so it has not been susceptible to the same bugs that standard Gmail users have faced.

New version of Gmail

Once Gmail moves these customers to the new version, we're likely to see problems. I wonder why they haven't done this yet. The bigger question is, with my organization's growing use of this particular tool, should we prepare for the change by using a plug-in that supports the new interface?

At any rate, it was cool to see the script being used in my own organization! It may be a good idea to seriously consider moving the script to Gmail's Greasemonkey API to support the new interface.

Google Releases New Version of Gmail

Google has released a new version of Gmail. The ui parameter that appeared in the URL recently, the one that broke the HTML Reply Signatures for Gmail Signatures Firefox Extension and Greasemonkey, was part of the plan for allowing users to switch between the newer version and the older version.

How to Go Back to Gmail's Older Version explains more of the details regarding the new version features as well as how to switch back to the older version.

I just bought a 1968 Ford Thunderbird! I bought it yesterday actually. It hasn't even been 24 hours! It has a 429 cubic inch big block V8, suicide doors, a nice, well-preserved leather interior, and driving this well-engineered machine is like stepping back in time! It also has enough power to propel you into tomorrow!

And just how does this relate to the Gmail Reply Signatures Extension you ask? Well, it will be awhile before I will be able to fix this newly created Gmail bug, so for now, I'm going to recommend that you use the older version of Gmail so you can still use your HTML Signatures. Fortunately, Google is good at allowing us to enjoy backwards compatibility for awhile.

I'll post pictures of the car soon!

The Gmail Dependency

I knew it was going to happen one day, I just wasn't sure exactly when. I knew one day the script would suddenly stop working. Not because code rusts. Or because the code cracked like glass, but because the foundation that it depends on cracked.

Well, it didn't really crack. It's more like what happens when a house settles. It's just digging itself in. Gmail was digging itself in. The developers added a new parameter to the URL that opens the HTML Compose editor. ui=1. If they added it to the end of the URL, it wouldn't have made a difference. But regular expressions care about where certain things are placed. Order doesn't matter in a URL parameter list, so Google developers could put this parameter wherever they wanted.

However, the script stopped working. The regular expression logic asks if the URL matches a specific "include" pattern. For most URLs, nothing happens, the script does nothing. There's no need to use processor power unnecessarily if there is no Gmail HTML content window to paste HTML into. Plus, users may get annoyed if the HTML popped up somewhere unwelcome.

If the URL were to match the pattern, then the code is executed. The HTML is read from an XML data file, as is the Greasemonkey Script. At a specified location in the script, JavaScript variables are generated, which contain the HTML retrieved from the XML file. This re factored JavaScript is then evaluated and dynamically inserted into the HTML content window of Gmail, using a compiled Greasemonkey engine.

An asterisk is all it takes. One small character, just 2 bytes of data, is enough to break functionality.

HTML Multiple Reply Signatures for Gmail is dependent on the functionality of Google's Gmail interface. The URL change was an easy fix, but should Google decide to perform a major overhaul of the Gmail interface, the HTML Multiple reply Signatures for Gmail scripts and Firefox Extension would reach the end of their useful lives. Better Gmail, and many other Firefox extensions built around Gmail's interface, such as Gspace, may also be rendered useless.

- Click the "Edit" button.

- Add the asterisk where indicated by the highlighting.


For all of the do-it-yourselfers, I highlighted the area where I had to make the change. If you're using one of the Greasemonkey scripts, the Firefox Extension, or another type of HTML Signature injector script that recently broke, you can fix it by making sure that highlighted asterisk is added to the included URL or regular expression. That's right! Even if you're using another Gmail HTML injector script other than one that I created, you can fix it yourself by editing the include URL list and correcting any errors!


Of course, if you find that you would rather get a new, updated copy, all of the links in the menu on this website reflect the updated URL changes. Since installing or reinstalling the scripts should fix the problem, you could just download a new copy and reinstall it.

Update for HTML Multiple Reply Signatures for Gmail

10/09/07 UPDATE: Due to a change made to the Gmail URL structure, the HTML Multiple Reply Signatures Extension suddenly stopped working. I've updated the URL to reflect the newest, working version.

There have been some problems with the Firefox Extension that can make inserting HTML signatures in Gmail somewhat of a hassle. However, in spite of these issues, people have been downloading and using it. To my surprise and pleasure, I've received quite a bit of positive feedback. For those of you who have given me feedback, thank you! In order to address some of the issues that you've had and to accommodate some requests I've received, I've updated the extension, which can be downloaded by clicking on the following link:

Multiple HTML Reply Signatures Extension 1.0.2

Multiple HTML Reply Signatures Extension 1.0.2.1

Multiple HTML Reply Signatures Extension 1.0.2.2


I've added multi-line functionality to the editor, so you won't have to type the HTML all on one line. In addition, this should make it much easier to paste HTML directly into the editor. This was causing the script to not function when HTML was pasted, since HTML is typically not written all on one line.



I also added an update notification to the new version. Firefox Extensions support update notifications through RDF, but since my hosting provider doesn't respond to RDF requests with "text/rdf" like an Apache server would, I was forced to create a hack that uses a regular expression to check the version number against my server. The cool thing about my custom version of update notifications is that the HTML Multiple Reply Signatures for Gmail extension will simply insert a "Click here to update" button in the tool bar.



It's not the most elegant way to notify users of an update, but I absolutely hate popup windows. This tool bar button is very unobtrusive. An image or a logo would be cool, but that's not my specialty so for now, it's plain text.

I started looking into the issue of why quotes won't work in the extension. This is turning out to be a lot more complicated and will take a lot more time to resolve. The problem is that the quotes have been escaped so many times that I think the strings aren't being parsed correctly. For now, you must enter your attributes without quotes like I've done below:

<a href=http://blog.opensourceopportunities.com style=color:orange>Blog</a>

Oh, I recently discovered that ampersand codes weren't supported. That has also been fixed. You can now use   in your HTML, if needed.

I'll continue to fix bugs in this extension. The quotes are a big one, but not easily fixed. As always, if you have any problems, questions, concerns, or suggestions, please email me and I'll respond as quickly as I can.

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

HTML Multiple Reply Signatures for Gmail Firefox Extension

After spending the last three weekends working on the HTML Multiple Reply Signatures for Gmail Firefox Extension 1.0.1, I finally have a working prototype.

The Firefox Extension has all of the features and functionality of the HTML Multiple Reply Signatures for Gmail Greasemonkey script, except the extension doesn't require Greasemonkey. In addition, the extension provides a user interface for easy editing of signatures.

With Greasemonkey, users are required to edit the script manually in order to edit signatures. With the extension, this is no longer necessary.

For convenience, there is a real-time preview window so any HTML entered is immediately displayed for easy editing.

In fact, I'm thinking that the preview editor has some potential to be used in a number of applications, such as an HTML tutorial, HTML-area textbox for user comments, possibly a content-management system, and some other uses.

Since the user interface consists of XUL, these applications would all have a client-side feel to them, yet the potential exists to either serve them remotely or package them as Firefox Extensions.

The Firefox Extension

You should be able to install the extension in Firefox simply by clicking on the HTML Multiple Reply Signatures for Gmail 1.0.1 Firefox Extension link. If you are prompted to install, wonderful! Simply choose the "Install" option and restart Firefox. However, I noticed that -- when I tried to install by clicking on the link -- I was instead prompted to save the XPI file to disk.

If you experience this, follow these steps to save the XPI to disk and install it locally.

• To install the XPI locally, open the Extensions/Add ons window from the "Tools" menu.
• Next, drag and drop the XPI file from your desktop to the extensions window.
• When prompted to install, click "Install".


• Restart Firefox by closing all Firefox windows.

Using the HTML Multiple Reply Signatures for Gmail Firefox Extension

Creating a signature

• In Firefox, click "Tools" -> "Gmail Multiple Reply Signatures".





• Near the top of the window are two radio buttons. Use these to toggle between editing the signatures for initial compose emails or reply emails





• In the "Initial Composes" section, select from four signatures to configure.





• Enter HTML in the "Enter HTML Signature here" section. For attributes, do not use any quotes. Below is an example of a signature hyperlink where attributes are used, but without quotes:


<div>--</div><a href=http://blog.opensourceopportunities.com style=font-family:tahoma;color:blue;>James Mortensen</a><div></div>




• In the "Preview" section, you will see real-time HTML output based on your input in the "Enter HTML Signature here" section. You may fine-tune your signature until it appears the way you want.





• Once configured, click "Save".

Inserting the HTML Signature in Gmail

Inserting the signature is automatic. When you click "compose" or "reply", the first signature in the list will automatically appear in the editor. To change signatures, use the dropdown list at the bottom of the Gmail left navigation section. The signature will be changed automatically as soon as your selection is made.

View the demo here.

Known bugs

There are some bugs that I have come across so far, and I am sure that there will be more. If you discover a bug that is not in this list, please email me or post a comment to this post.

Sometimes it is best to release software instead of trying to correct every single bug. None of these are showstoppers, but here they are:

• Quotes cannot be used around attributes

Simply leave out the quotes as they are not required.



• Large sections of HTML may be corrupted when saving.

When you enter large sections of HTML and save, the next time you open the sgnature content editor, you will be reverted back to defaults. You can find your signatures in an xml file called htmlmultiplereplysignaturesforgmail.xml in your Mozilla Firefox profile directory. Save this information somewhere else, or copy and paste the non-corrupted signatures back into the editor. I plan to create some means of recovery for these types of errors.



• The signature names can't be renamed

This functionality has not been completely implemented yet.



• When pressing "Compose" in Gmail more than once, multiple drop-down lists appear

Just delete any unwanted signatures from the Gmail editor.



• After entering email content, selecting a different signature will cause part or all of my email to be deleted.

Be careful not to type below the "--" characters. There are invisible markers around he signature that mark the dynamic section. (Actually, the signature is placed inside a span element. If you type below the "--", you are typing inside the span element).


• Fixed in 1.0.1 on 6/9/07 - After entering a signature on multiple lines in the editor, the signatures would not appear in the Gmail compose or reply editors.

I enabled the multiline attribute of the textbox, which the script did not know how to handle. The temporary fix was to disable multiline support until I have time to fix the problem and test it thoroughly. Be aware that if you want line breaks in the signature, simply use a <br> or <div></div>

Comments

This is the first project I've done on my own that is outside the context of work or school. Please don't hesitate to give me advice about how to better track bugs, write better documentation, or make improvements to the application.

Also, if you have any trouble or need help, please contact me. I hope you find this Firefox extension useful!

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