Archives

How long before Pong? Battleship, a pretty easy game to implement, has made it’s appearance as an AJAX powered game.

It has a few defects: if you reload the page it repeats the dialog and puts you back into the setup phase which made the UI get out of sync with the game state. Also, my opponent was apparently unable to shoot after he hit my first ship. The chat function was marvelous for commiserating about how the game didn’t work.

The game makes use of many of the most popular Javascript libraries.

<script src="js/import/prototype.js" type="text/javascript"></script>
<script src="js/import/scriptaculous.js" type="text/javascript"></script>
<script src="js/import/effects.js" type="text/javascript"></script>
<script src="js/import/window.js" type="text/javascript"></script>
<script src="js/import/dragdrop.js" type="text/javascript"></script>
<script type="text/javascript" src="js/chat.js"></script>

I’d say it’s good for one play before the tears of boredom stream down your face.

Ajaxian alerts us that Jotspot has partnered with Salesforce.com to produce a collaborative spreadsheet-like application.

Check out the inner popups, formulas, security selections, etc. This
really shows how you can build an application that looks like a desktop
app but also has the mashup ability shown off too.

In this case the Salesforce.com application provides the backend model for the collaborative spreadsheet application. It does more than just provide a spreadsheet, however. It includes task tracking and calendaring.

What are Jotspot’s plans for the application going forward? From the original article:

The salesforce.com/Tracker partnership is a good example of Jotspot’s
strategy to "embrace and extend Microsoft", which Jotspot CEO Joe Kraus
and I spoke about previously in my post in March.
With JotSpot Tracker integrated into salesforce.com, there is no need
to download Excel files to the desktop – because everything is
available on the Web via the Salesforce service. Which of course is one
of the steps towards a Web Office suite!

Embrace Microsoft? That had better be a massive bearhug. Good luck.

I had intended to marry the nice Apache2 event MPM and Jetty 6 with Continuations in order to achieve a thrifty, thread-sparing COMET capable Java app. The idea is that the Event MPM module in apache frees up a thread when an open connection to the browser is snoozing and Jetty frees up a thread when the backend servlet is snoozing. There are two problems, however.

1. The Event MPM module seems to only snooze between requests. With COMET the need to snooze happens during a requests, i.e. we are expecting something to come back from the server.
2. The request handler module — in this case mod_jk or mod_proxy_ajp — and not the Event MPM module handles the socket connections to the servlet container. From my reading of the most recent SVN branch, the modules are using blocking I/O and not polling.

It seems there’s still a bit of work to be done to make Apache and Jetty do the COMET dance.

We saw an announcement a few days ago of AjaxOS, an application suite bundled in an AJAX "desktop." So now we can all use productivity apps online and pretend we are using our own computers. It turns out that the concept of an AjaxOS isn’t exactly new. Over at webbys.world we have a more extensive overview of other AjaxOS’s. The best of these seems to be eyeOS.

I get a kick out of opening another AjaxOS in the eyeOS web browser. Down the rabbit hole.

Management abhors a vacuum. That’s why when there are no workable information systems in place, spreadsheets and email chains spring up to fill the gap. Anyone who has tried to tame one of these organic sneaker-nets knows how hard they are to uproot.

One of the reasons they are so resilient is that they work pretty well for the users involved. The user interface is familiar to all of them, and writing a spreadsheet is a heck of a lot easier than writing reports in crystal and entering data in a disconnected and unwieldy forms interface.

The downsides for the larger business are, of course, the reason why senior management typically tries to eradicate theses ad hoc systems is that their business data is stuck, unversioned and unverified, in employees inboxes and file-systems. They break down as they grow and as spreadsheets are invariably modified, often in incompatible directions, in response to changing and growing business requirements.

The response is to implement a variety of replacement solutions: Knowledge Management Systems, data entry and reporting solutions, work-flow and OPM systems. These solutions tend to be expensive, slow to implements, and ultimately unsatisfying replacements.

Why not embrace the spreadsheet and integrate it with the KM/work-flow/reporting systems? Collaborative spreadsheets, with roll-ups, entitlements, work-flow — the killer App of the AJAX era? There are already a few AJAX spreadsheets — Num Sum has a good one — and in a blast from the past, Dan Briklin, one of the creators of VisiCalc, is working on WikiCalc. Don’t get too excited. WikiCalc doesn’t have any of those necessary things — work-flow, roll-ups, reporting — that would make this a killer app.

Bit even if the perfect solution comes along in a few months, that’s no guarantee of success. One secret to implementing information systems that are successfully adopted is this: eliminate the competition. In the case of a collaborative spreadsheet system this means eliminating email attachments, desktop spreadsheet applications, shared file-stores, etc. The AJAX collaborative spreadsheet may be a little ways away from being able to replace the current desktop solutions, but their time may come.

At any rate, these office apps are unlikely to be Microsoft’s Pearl Harbor or anyone elses.

Alex Bosworth over at Source Labs has a blog entry up entitled 10 Places You Must Use Ajax. I count six places you should use them and six that you shouldn’t. His arithmetic aside, he makes some good points about where  AJAX can be  employed, mostly from a general usability standpoint. For instance,

• Deep hierarchical tree navigation.

  First of all, applications with deep hierarchical tree navigation
  are generally a nightmare. Simple flat topologies and search/tagging
  works very well in most circumstances. But if an application really
  calls for it, use Javascript to manage the topology ui, and Ajax to
  lessen the burden on the server by lazy loading deep hierarchy data.
  For example: it’s way too time consuming to read discussion threads by
  clicking through and loading completely new pages to see a one line
  response.

In point of fact, these types of uses are already commonplace. I’d add one big category that he missed, namely the Direct Manipulation Interface. From the wikipedia definition:

Direct manipulation is a human-computer interaction style that was defined by Ben Shneiderman
and which involves continuous representation of objects of interest,
and rapid, reversible, incremental actions and feedback. The intention
is to allow a user to directly manipulate objects presented to them,
using actions that correspond at least loosely to the physical world.
Having real-world metaphors for objects and actions can make it easier
for a user to learn and use an interface (some might say that the
interface is more natural or intuitive), and rapid, incremental
feedback allows a user to make fewer errors and complete tasks in less
time, because they can see the results of an action before completing
the action. An example of direct-manipulation is resizing a graphical
shape, such as a rectangle, by dragging its corners or edges with a
mouse.

Google Maps is a good example of this style as realized in AJAX, as are the drag-and-drop aspects of many of the new AJAX enable mail and calendaring applications. The places to look for good uses of this style are existing desktop applications. In fact, beyond direct manipulation, there are a number of other techniques worth using as we move from the simple data report applications that Alex envisions and the more document centric apps of the web future. It is the user’s experience with these desktop applications that will make their introduction in the web effective — in short, the user already knows how things should work.

• Use visual metaphors whenever appropriate

Alex argues that "a slider to pick the price to the cent is just overkill." I agree, but that’s not an argument not to use a color picker or a slider to manipulate contrast settings in an image within a CMS.

• Spacial data manipulation

We’ve already mentioned Google Maps as one example of this. Management and monitoring of nodes and edges, such as UML class diagrams, Physical computer networks, BPM diagrams, are also a staple of desktop apps that are now within reach of the webapp with AJAX.

• Modal dialogs for presentation of finite tasks

Ironically, it is the use of modal dialogs within the AJAX app that makes the webapp less modal as a whole. It removes the need for separate data entry and support screens — two distinct "modes" of the program. As it stands now you have an unpleasant choice, as popping up non-modal browser windows to perform modal tasks is problematic.

• Modeless dialogs for presentation of ongoing tasks

Displaying controls and results in modeless dialogs allows users to work their way rather than in a tightly constrained flow dictated by the application designer. Searching and search results, detail information, task lists,  tool bars,  contextual help — all optional or peripheral information that can benefit from modeless dialogs.

• Visual Feedback for long-running tasks

That’s right, long running tasks. It was awkward tracking ongoing processing before AJAX. Now that we can handle them, we should use thing like progress bars to give users an idea of what exactly is going on or dynamic tooltips to allow users to investigate status on demand.

• Application level undo instead of the Back button

When manipulating documents instead of doing CRUD, the back button can be pressed into service as an undo, but it takes some work. Better to use application level undo than the ham handed back button. Do you search the interface of your word processor or the documents on the hard disk? Do you email a bookmark to a particular UI state or the document you’ve produced?

• Contextual controls

Don’t display all the controls — buttons, sliders, tree controls — at once. Display only high level controls and display new controls as you display new context. This is especially important when we are working on documents rather than reports. For example, AJAX based word processors should not display controls for editing headers and footers at the same time as displaying the controls for editing the main body.

This is just a sampling of what it a rich body of knowledge from the world of desktop WIMP GUI’s can yield to the astute AJAX developer.

Alex seems to disagree with the use of some of the above applications because they are either too bandwidth intensive or because they lead to poor application design. Actually, it seems he’s just plain opposed to the use of AJAX for anything beyond data updates. I agree that if write the new AJAX apps the way we’ve designed the layered form-and-reports page oriented applications of the past, adding any sort of sophisticated UI styles will lead to some major spaghetti code. You need to think outside the box for this sort of application, otherwise you as a developer will spend more time writing the same old forms and reports apps with a little bit of AJAX sugar, while other programmers are cranking out Rich Interaction Applications in a fraction of the time.

That’s why I recommend looking at the various component based GUI’s for AJAX, either the client side ones like Tibco GI or OpenLaszlo (for DHTML) or the server side ones like Echo2.

I’ve always thought that one of the big advantages of a component GUI
framework was that you are able to leverage all of those prewritten
components to produce something rather spiffy with very little original
code.

I gave a presentation on AJAX and Component GUI’s this
past Wednesday in Chicago and highlighted Echo2 as a framework worth
investigating. To demonstrate it’s power, I showed off an application
that clocked in at 298 lines of code. That’s including the code to pull
the stock quotes from a web service via the Mule ESB (a very nice choice, IMHO if you need to do async background processing).

The app can be found here. It’s on a somewhat underpowered server, so don’t mention it on slashdot.

The app allows you to drag stock symbols from a left column into a
right, where they turn into market data grids. You can drag these grids
back again. The quotes are updated every 15 seconds or so. It’s of
course much more interesting when the markets are open.

I’ve
intentionally left it a limited demo, i.e. you can’t add in other stock
symbols, since I don’t want people to be tempted to use this as a real
stock ticker and burry me with traffic. I do plan to include this app
as an example in my tutorial series.

I made use of Echo2,
Echo2_Contrib and EPNG for the app. It caused quite a stir, since folks
in the audience (designers and developers for the most part) had a good
sense of what it might take to bang something like it out in DWR or
some other framework.

So, the challenge: what can you do in 300
lines of code? Be honest, count Javascript, XHTML, Java, etc. Then let the best demo win.

Update 1: To determine "lines of code," I’m counting semicolons in Java and Javascript, CSS entries, and XHTML entities. Since I’m only writing Java, all the others sum to 0.

I gave my presentation last evening to a welcoming Chi2 audience. The attendees were a good mixture of developers, designers and business folks. They sat through my rantings on why I thought Rich Interaction Applications (RIA) in AJAX should be developed with server-side component based GUI’s, though, in a pinch, I could see the argument for client-side component based GUI’s that use the back-end as a dumb data web service. Then I showed them what 150 lines of Java code could do in the Echo2 framework with my special "why would you do things this way" stock quote app. Lot’s of dragging and dropping ensued.

I’ll put the presentation and the demo up when I get a chance.

One of the more interesting and probing questions after the talk was about business logic leakage, i.e. how does a server-side component GUI (SGUI) keep you from leaking business logic? The answer is simple: with the SGUI, the only "logic" that makes it to the browser is "turn this area blue," "move this button over here," and "make this element draggable." While I suppose it is possible to leak business logic in this way, I’d have to say that the possibility is pretty remote and esoteric, akin to sending smoke signals.

In the pseudo hand-coded world of traditional webapp development, you are dependent on developers following good practices and not making mistakes, such as leaking the secret sauce in their Javascript validation logic. At least you hope they do. If the last 50 years of software development practice have taught us anything, it’s that hope is not a plan.

There are two kinds of information leak — what and how. "What" is your customer data, your orders, your accounts receivable, your employee database. The "how" is your secret sauce, the special way of pricing or quoting or doing that gives you a competitive advantage. Reports can leak the "what," and many businesses can survive a leak of quite a bit of "what," but leak the "how," your secret sauce that makes you money, and you’re cooked. Javascript can leak the "how" if you let it.

Michael Mahemoff feels it’s sometimes OK to include business logic in the Javascript:

I realise there are plenty of problems with Javascript business
logic, and it’s certainly not always applicable. Those problems include:

• Security – Exposes business logic algorithms and enables them to be changed.

That first bit applies to most all valuable services that a company might provide. If all you’re providing is data, then no business logic would be leaked. If you are performing some sort of business logic on the data, it would have to be something pretty trivial to still have value and not be a divulging of the crown jewels. Can a business consist of a bunch of ultra trivial, obvious logic and still be competitive? Probably not. In short, I can’t imagine the circumstances where that first item wouldn’t just preclude exposing most any business logic.

It seems the evolution of games that happened on the PC and on-line is repeating itself in the AJAX arena. First come the board games — see Ajax Chess, 64Pola, and Morfiks — and the muds — hive7, then the low fidelity arcade games, then the first person shooter games. Is AJAX Doom too far away? Yeah, probably.

The chess games are actually pretty lousy, more experiments in Ajax rather than real apps. I’ve written a few chess games in my time and will take a crack at one that incorporates back-end access to a chess engine. Why reinvent the wheel? Just expose a FEN web service wrapper over a winboard engine like crafty.

The truth is that for the first person shooters and other higher perf stuff, flash is better than AJAX based apps are likely to be (See here for everything from Doom to WarCraft to Mortal Kombat in Flash). In truth, if you scratch below the surface a bit, what differentiates something like Flash and Java Applets from AJAX for any sort of application is the install and startup overhead. OpenLaszlo can communicate with the server just fine, thank you, and Java Applets have been able to do that since the beginning. So why all the hype over AJAX now?

Now that it’s all wrapped into the browser, it seems tempting to move to AJAX. It’s already in there, so they can’t resist like they can with Flash and Applets. What are they going to do, turn off Javascript?

But for everyone from those developing public facing to intranet apps, there’s reason to look beyond the buzz of AJAX. If you’re making the move to interactive, rich client user experience, is AJAX really the right choice? Do you trust your Ajax framework vendor enough or do you have deep enough pockets to keep your apps up-to-date with the changing browser landscape? Is the kind of rich client experience you are after achievable with AJAX? Why didn’t you go with the other technologies in the first place and settled on a forms-and-reports conventional webapp instead?

Go over your reasons again or you may find yourself implementing Doom in AJAX.

Update 1: pitstreet.com has an assortment of Javascript games, including some that employ AJAX. Their usability leaves something to be desired. Just try to find the chess or reversi games.

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on
millions of lines of code. Three or four engineers and a steady supply
of Red Bull is all it takes to rapidly turn a midnight brainstorm into
a website so hot it melts the servers.

What has changed is the way today’s Web-based apps can run almost as
seamlessly as programs used on the desktop, with embedded audio, video,
and drag-and-drop ease of use. Behind this Web-desktop fusion are
technologies like Ajax (asynchronous JavaScript and XML), Macromedia’s
Flash, and Ruby on Rails. We’ll spare you the technical details;
suffice it to say that these technologies are giving rise to a new
webtop that may one day replace your suite of desktop applications.

I already hate the term "webtop," though I’ve used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We’ll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance – why aren’t most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It’s more than just CRUD on speed – even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80′s, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn’t see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain’t Word – more like Wordpad. If Writely was out as a desktop app, it wouldn’t get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? – You’re not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn’t change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can’t come up with a good answer, odds are it doesn’t add a thing.