Agile Ajax

Two Years of Agile Ajax: Web Killed Off GUI Techniques Just in Time for Ajax to Need them Again

I launched this blog just a little over two years ago, on March 21st, 2006. Appropriately enough, my first post was about User Experience (UXD) and Ajax. The blog has come a long way since then -- we've added another full-time blogger (Brain Dillard), published nearly 700 articles of original Ajax and Agile related content, and covered the major new innovations in Ajax and Web 2.0 -- but in many ways Ajax technology is still struggling with the same issues that I wrote about back then:

As it stands, Ajax is still in its infancy (or in its wild west phase -- pick your metaphor), and Bill's simple three part "patterns" are emblematic of this.

 

Save That Duck!

So, while most of you were off celebrating the holidays, Dietrich was off killing a duck, or at least Duck Typing. Personally, I always thought that the goose was the traditional holiday bird.. shows what I know.

Deitrich's argument is that Duck Typing does not allow "Dead Duck Typing", being able to restrict access to part of an object's state or functionality. The classic case here is keeping a display layer from getting at the persistence layer. (Maybe we can call this Stephen Colbert Typing, since you're declaring part of the object as "dead to me"...)

Dietrich closed his post with:

Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.

Which I think is my cue.

I understand the theoretical argument for having strict (or stricter) access control in a system, and I certainly understand why having small, high cohesion classes is a good thing. My problem is that it's very rare for me to have a practical issue in a system because of loose access control or overly generous interfaces (granted, I've had a good run of working with smart people). On the other side, I commonly find that when I'm writing a program with access control I'd like to do something more flexible with an object, but I can't, because the original writer of the class did not anticipate the usage.

Specifically on the Ruby side, it's actually not hard at all to restrict access to an object. ActiveRecord objects can easily be made read only called before being passed to a view to protect from inadvertent changes.

In the more general case, it's not hard to do something like this, which only allows certain methods of an object to be called:

class ArbitraryProxy

  def initialize(object, *methods)
    @object = object
    @methods = methods
  end

  def method_missing(method, *args)
    if @methods.include? method
      return @object.send(method, *args)
    end
    super
  end

end

x = ArbitraryProxy.new("abcd", :size, :gsub)
p x.size
p x.gsub("b", "---")
p x.upcase

This returns:

4
"a---cd"
NoMethodError: undefined method ‘upcase’ 

The interesting thing is that, by and large, Rails developers don't feel the need to do this. I don't think I've ever seen an authoritative source suggest that it's best practice to make ActiveRecord objects read only before passing them to the view.

There is a Rails plugin called Liquid that enforces the use of proxy objects before being passed to the view. It's not very widely used (in part because creating the proxies is kind of a pain).

I don't see that Ruby and Rails programmers see this issue as a practical problem facing them (it helps that Ruby tends to encourage small classes in other ways). That said, there are clearly cases where you need to be extra careful. Liquid is used as user-facing templating engine for a blog tool, which is clearly a case where you'd want to limit the damage that your template writers can do.

But I see that as the exception, not the rule. Long live the Duck!

---

Coming Soon: Professional Ruby on Rails -- available in bookstores Mid-Februrary.

Technorati Tags: ruby, OOAD, Duck Typing

Pimp my Webapp: Turning Web 1.0 into Web 2.0, Part 1

Everyone wants the Web 2.0. But how to get there, especially if you have a dowdy old Web 1.0 application? Will I have to spend the annual GDP of a smallish Central American nation on the rewrite? There are three general approaches that evolved over the last year:

1. The Christmas Tree Approach - decorate your Web 1.0 app with Ajax widgets and simple backend JSON or XML services. Pro: doesn't require major investment. Con: app still mostly suffers from the Web 1.0 downsides -- postbacks, CRUD, etc.
2. The Refrosting the Cake Approach - transform all of your views from HTML to JSON or XML. Develop a client side GUI that calls your applications controllers and views. Pro: doesn't require full rewrite. Con: control flow moves from server side to client side; won't take full advantage of RIA opportunities, such as direct manipulation or document-centric interfaces; really just a nice face on CRUD.
3. The From Scratch Approach - take the opportunity to rethink your application as something other than the web equivalent of a green screen. Imagine Photoshop or Word as a traditional webapp. Pro: unencumbered by the old system. Con: costly; you may lose your way in reinventing your app.

I think approach #2, Refrosting the Cake, is actually quite appealing. You can make using that dowdy old webapp quite a bit more pleasant with a quick coat of Ajax. There was a really interesting article on this written by Brian Walsh back in July of 2006. It sort of got lost as a pure Tibco GI article, but it has much wider applicability. In it, Brian uses XStream to convert the views of a SpringMVC sample application from HTML to XML. He then uses Tibco GI to build a UI that talks to the controllers and views on the back end.

I used a similar approach to convert a dowdy old application -- mwhois -- to Web 2.0. Instead of Tibco GI, I used GWT. And instead of XML, I used JSON.

The old application looked somewhat homely...


...and suffered from the kludgey flow and heavy postbacks typical of Web 1.0. I proceded to identify the different views and converted them (via mwhois' templates) into JSON.

simple search: domain=agiledev&ext=com

{ "isAvail" : false,
  "domain" : "agiledev",
  "ext" : "com",
  "whoisServer" : "whois.crsnic.net" }

raw record: domain=french&ext=biz&show_raw=1

{ "domain" : "french",
  "ext" : "biz",
  "raw" : "Domain Name:                                 FRENCH.BIZ\nDomain ID:                                   D2708502-BIZ\nSponsoring Registrar:                        COMMUNI GAL COMMUNICATIONS LTD.\nSponsoring Registrar IANA ID:                418\nDomain Status:                               clientTransferProhibited\nRegistrant ID:                               GC683CO965021\nRegistrant Name:                             jamil akhtar\nRegistrant Address1:                         Regent House\nRegistrant Address2:                         24-25 Nutford Place\nRegistrant City:                             London\nRegistrant Postal Code:                      W1H 5YN\nRegistrant Country:                          Great Britain (UK)\nRegistrant Country Code:                     GB\nRegistrant Phone Number:                     +44.7729391052\nRegistrant Facsimile Number:                 +44.2075693152\nRegistrant Email:                            jamil@cityfinancialcorp.co.uk\nAdministrative Contact ID:                   GC683CO965021\nAdministrative Contact Name:                 jamil akhtar\nAdministrative Contact Address1:             Regent House\nAdministrative Contact Address2:             24-25 Nutford Place\nAdministrative Contact City:                 London\nAdministrative Contact Postal Code:          W1H 5YN\nAdministrative Contact Country:              Great Britain (UK)\nAdministrative Contact Country Code:         GB\nAdministrative Contact Phone Number:         +44.7729391052\nAdministrative Contact Facsimile Number:     +44.2075693152\nAdministrative Contact Email:                jamil@cityfinancialcorp.co.uk\nBilling Contact ID:                          GC683CO965021\nBilling Contact Name:                        jamil akhtar\nBilling Contact Address1:                    Regent House\nBilling Contact Address2:                    24-25 Nutford Place\nBilling Contact City:                        London\nBilling Contact Postal Code:                 W1H 5YN\nBilling Contact Country:                     Great Britain (UK)\nBilling Contact Country Code:                GB\nBilling Contact Phone Number:                +44.7729391052\nBilling Contact Facsimile Number:            +44.2075693152\nBilling Contact Email:                       jamil@cityfinancialcorp.co.uk\nTechnical Contact ID:                        GC683CO965021\nTechnical Contact Name:                      jamil akhtar\nTechnical Contact Address1:                  Regent House\nTechnical Contact Address2:                  24-25 Nutford Place\nTechnical Contact City:                      London\nTechnical Contact Postal Code:               W1H 5YN\nTechnical Contact Country:                   Great Britain (UK)\nTechnical Contact Country Code:              GB\nTechnical Contact Phone Number:              +44.7729391052\nTechnical Contact Facsimile Number:          +44.2075693152\nTechnical Contact Email:                     jamil@cityfinancialcorp.co.uk\nName Server:                                 DNS.INTER.NET.IL\nName Server:                                 NS.COMMUNIGAL.NET\nCreated by Registrar:                        COMMUNI GAL COMMUNICATIONS LTD.\nLast Updated by Registrar:                   COMMUNI GAL COMMUNICATIONS LTD.\nDomain Registration Date:                    Wed Mar 27 00:01:00 GMT 2002\nDomain Expiration Date:                      Wed Mar 26 23:59:59 GMT 2008\nDomain Last Updated Date:                    Mon Mar 12 16:25:34 GMT 2007\n\n>>>> Whois database was last updated on: Sun Oct 14 17:51:14 GMT 2007 <<<<\n\nNeuLevel, Inc., the Registry Operator for .BIZ, has collected this information\nfor the WHOIS database through an ICANN-Accredited Registrar. This information\nis provided to you for informational purposes only and is designed to assist\npersons in determining contents of a domain name registration record in the\nNeuLevel registry database. NeuLevel makes this information available to you\n\"as is\" and does not guarantee its accuracy. By submitting a WHOIS query, you\nagree that you will use this data only for lawful purposes and that, under no\ncircumstances will you use this data: (1) to allow, enable, or otherwise\nsupport the transmission of mass unsolicited, commercial advertising or\nsolicitations via direct mail, electronic mail, or by telephone; (2) in\ncontravention of any applicable data and privacy protection acts; or (3) to\nenable high volume, automated, electronic processes that apply to the registry\n(or its systems). Compilation, repackaging, dissemination, or other use of the\nWHOIS database in its entirety, or of a substantial portion thereof, is not\nallowed without NeuLevel's prior written permission. NeuLevel reserves the\nright to modify or change these conditions at any time without prior or\nsubsequent notification of any kind. By executing this query, in any manner\nwhatsoever, you agree to abide by these terms.\n\nNOTE: FAILURE TO LOCATE A RECORD IN THE WHOIS DATABASE IS NOT INDICATIVE\nOF THE AVAILABILITY OF A DOMAIN NAME.\n" }


global search: domain=agilesoftware&do_global=1

{ "domain" : "agilesoftware",
  "avail" : [{ "domain":"agilesoftware","ext":"biz" },{ "domain":"agilesoftware","ext":"be" }],
  "unavail" : [{ "domain":"agilesoftware","ext":"com" },{ "domain":"agilesoftware","ext":"net" },{ "domain":"agilesoftware","ext":"org" },{ "domain":"agilesoftware","ext":"co.uk" },{ "domain":"agilesoftware","ext":"info" }] }

wizard search: do_wizard=1&company=pathfinder&keyword1=uxd&keyword2=agile&ext=com

{ "whoisServer" : "whois.crsnic.net",
  "avail" : [{ "domain":"pathfinderuxd","ext":"com" },{ "domain":"pathfinder-uxd","ext":"com" },{ "domain":"uxdpathfinder","ext":"com" },{ "domain":"uxd-pathfinder","ext":"com" },{ "domain":"pathfinder-agile","ext":"com" },{ "domain":"agilepathfinder","ext":"com" },{ "domain":"agile-pathfinder","ext":"com" },{ "domain":"uxdagile","ext":"com" },{ "domain":"agileuxd","ext":"com" },{ "domain":"uxd-agile","ext":"com" },{ "domain":"agile-uxd","ext":"com" }],
  "unavail" : [{ "domain":"pathfinder","ext":"com" },{ "domain":"pathfinderagile","ext":"com" },{ "domain":"uxd","ext":"com" },{ "domain":"agile","ext":"com" }] }

Then I wrote a simple, tabbed interface using GWT and the MyGWT widgets and slapped the two together.



I'll have more details on the code details in part 2 of this article. For now, you can look at the old and new interfaces.

Technorati Tags: ajax, gwt, mygwt, tibco gi, JSON, XML, web20

YUI Bubbling Library: a seriously cool design pattern

Caridy Patino recently posted to the YUI Blog about his event-bubbling library, which uses the subscriber/publisher design pattern to abstract an entire webapp's event binding into its own unobtrusive behavioral layer. Instead of attaching events to individual DOM nodes using addListener, you intercept and process all events near the document root, then use CSS classes or other criteria to match up individual events with the correct handlers. In effect, you end up with a big, global switch statement for handling mouse clicks, mouseovers, keydowns and other events.

Patino, a respected contributor to the YUI mailing list, makes a strong case for the usefulness of his library on larger, more event-driven webapps. For one thing, it can reduce the overhead of handling IE memory leaks. For another, it can simplify the process of attaching custom JavaScript behaviors to dynamically loaded content. Best of all, it can be used to improve performance of really complex apps.

Of course, such an abstract approach isn't for every developer or every application. Patino is pretty frank about both the pros and cons of his approach for specific situations. Even if the actual technique isn't for you, though, the post is a fantastic primer on the intricacies of DOM events and the publisher/subscriber pattern.

• Read the post
• Check out the library

An Event Apart: Wrap-Up

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

Developer's Notebook: Useful OO JavaScript resources

My post about learning to organize classes without the semantic sugar of Prototype earned me some wide-ranging comments here and on Ajaxian. My favorite was Isaac Z. Schlueter Matthew Smith's proposal of a new framework: JLJ (Just Learn JavaScript). To that end, I thought I'd compile some of the most useful sites and posts I've come across in my quest over the last couple of years to employ better inheritance strategies in my JavaScript.

Let's face it, in the wide world of web development, for every dedicated client-side developer with a real taste for JavaScript, there are 10 Java middleware developers who believe that JavaScript isn't a "real" object-oriented language. Programmers with a broad range of experience in a wide array of languages will argue that JavaScript's loose typing, dynamic nature and prototype-based inheritance scheme are actually far more "object-oriented" than, say, Java or C++. That may be true, but there are lots of folks out there writing production code who have never written complex software using any language _but_ JavaScript. For these folks, myself included, JavaScript's dynamism is both a blessing and a curse. There's a lot of freedom, but not a lot of guidance. Languages that rely on good developer behavior rather than the intrisic properties of the language themselves can be dangerous. Just enough rope to hang yourself, and all that jazz. For those of us whose primary language is JavaScript, a little structural guidance can help a lot.

As the inestimable Douglas Crockford illustrates in Classical Inheritance in JavaScript, the main benefit to inheritance in a dynamic language is re-use. Most of us are interested in getting the most mileage possible out of every line of code we write. Many JavaScript frameworks enforce or encourage a particular method of doing this; most are modeled on the classical inheritance schemes of other languages. Every serious student of JavaScript should learn the strengths and weaknesses of these patterns - and how to implmenet them on the fly, without a framework to fall back on.

A note on this list: It's a highly subjective smattering of articles I found useful. Some are high-level discussions of JS itself, or of inheritence strategies in general. Others grapple with the interitance models of specific libraries in ways that highlight the underlying issues. I could post a completely separate list of JS/Ajax frameworks and their various approaches to the topic. But that's a different post for a different day.

On to the list:

Inheritance Strategies

• JavaScript: The World's Most Misunderstood Programming Language: Another Crockford classic. Start with this, graduate to the aforementioned inheritance article, and then lose a few days in the wilds of his site.
• Private Members in JavaScript: While you're there, check out this piece.
• Objectifying JavaScript: A strong tutorial from Digital Web.
• OOP in JS: An older but still-relevant multi-part case study in how to mimic class-based inheritance in JS.
• Correct OOP for Javascript: A didactic but persuasive look at classical inheritance models.
• Object Oriented Programming in JavaScript: A fairly dry but compelling paper examining a couple of different class-building strategies, based on an earlier 2003 paper.
• Prototype: Inheritance Madness: An examination of Prototype's approach to classes.
• Base: A JavaScript inheritance framework.

Closures, the Global Namespace and the Module Pattern

• Global Domination: A seminal YUI blog post about the dangers of the global namespace.
• Javascript Closures for Dummies: The title says it all...
• JavaScript Closures ... but this one says it more succinctly.
• A JavaScript Module Pattern: Another YUI blog post, this one annotating Crockford's module pattern.
• YUI's Module Pattern vs. Prototype's Class Function: Isaac Z. Schlueter's interesting post on Crockford's module pattern and how to extend it into a reusable constructor.
• Show love to the Module Pattern: More commentary on the module pattern.

Singletons, Lazy Constructors and Memoization

• JavaScript: The Singleton Design Pattern: A quick overview of singletons, with an interesting perspective on anonymous constructors.
• Lazy Function Definition Pattern: A blog entry from a functional-programming viewpoint.
• One-Line JavaScript Memoization: How to save overhead by doing the hard stuff once and saving it off.

Further Reading: DSLs, Aspect-Oriented Programming and More

• Metaprogramming JavaScript Presentation: Domain-specific languages and JavaScript.
• AspectJS: An AOP library for crosscutting concerns.
• Scope in JavaScript: Another piece from Digital Web, this time tackling how to master the this keyword, Function.apply and Function.call.
• Seven JavaScript Techniques You Should Be Using Today: Not specifically devoted to OOP, but a good roundup of best practices in general.

More on Cognitive Load - The Rendering Tier

In a comment to my post Friday on cognitive load and the supperiority of server-side AJAX GUI frameworks, reader Matt took me to task for muddling my tiers:

I would argue that mixing the middle tier (java) with the front-end (javascript, html, css) is the same as mixing the middle tier with the backend (db). In general, it is bad practice. Sure, some companies still directly access the db from inline sql, but the majority of developers agree it is bad practice.

While I agree with Matt that if you're going to adopt a layered architectural approach, you don't want to mix different subtasks into the same layer, simply putting code into the same physical environment or writing it in the same language does not constitute mixing layers. Rather than blindly following the "tiered approach," it is helpful to look at the original patterns source and understand its purpose. The first time I saw a formal discussion of the layered architecture pattern was in 1996 in the very useful Pattern-Oriented Software Architecture: A System of Patterns, Volume 1 by Frank Buschmann et al., Chapter 2, Section 2.2: From Mud to Structure. (Funny how some patterns in that book gained huge popularity, such as MVC, while more elegant patterns, like Presentation-Abstraction-Control, gain barely a mention.) From the text:

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

[snip]

The main structural characteristic of the Layers pattern is that the services of Layer J are only used by Layer J + 1-there are no further direct dependencies between layers. This structure can be compared with a stack, or even an onion. Each individual layer shields all lower layers from direct access by higher layers.

[snip]

Specify an interface for each layer. If Layer J should be a 'black box' for Layer J+1, design a flat interface that offers all Layer J's services. and perhaps encapsulate this interface in a Facade object [GHJV95]. The Known Uses section describes flat interfaces further. A 'whitebox' approach is that in which Layer J+1 sees the internals of Layer J. The last figure in the Structure section shows a 'gray-box' approach, a compromise between black and white box approaches. Here Layer J+1 is aware of the fact that Layer J consists of three components, and addresses them separately, but does not see the internal workings of individual components.

Good design practise tells us to use the black-box approach whenever possible, because it supports system evolution better than other approaches. Exceptions to this rule can be made for reasons of efficiency, or a need to access the innards of another layer. The latter occurs rarely, and may be helped by the Reflection pattern, which supports more controlled access to the internal functioning of a component. Arguments over efficiency are debatable, especially when inlining can simply do away with a thin layer of indirection.

The first observation I have is that writing our code all in Java still allows us to adopt a layered approach. The UI code can be nicely abstracted from the business layer, as people have been doing now for decades. Just because we are writing both in Java doesn't mean we are mixing the tiers.

The second observation I would make is that there is some confusion over which is the highest tier in web applications. As it's usually illustrated in architectural diagrams, the presentation tier sits on top. Certainly that's the way the end user sees it, and you can make an argument that that is how interactive applications should be architected, with the presentation tier using the services of the next tier down. I'd suggest a further refinement, one that's been creeping into web applications and various frameworks: the rendering tier. That's where the details of the underlying user interface device are abstracted as a set of functions for use by the presentation tier. That's precisely what Echo2 does, hide the details of HTML, Javascript, CSS, etc., in a rendering layer.

Although no other rendering implementations exist at present for Echo2 and ZK (another server-side framework), they are perfectly positioned to add support for Flash, mobile, desktop and other user interface devices.

So, my response to Matt is that we aren't mixing layers here, but -- staying true to the original intent of the architectural pattern -- improving the design of web applications by abstracting the details of the browser into a lower level rendering tier.

Technorati : ajax, cognitive load, complexity, layered architecture, patterns

An Interview with ZK Creator Tom Yeh

Anyone who has been following the development of AJAX frameworks has heard of ZK, the server-side component GUI framework that allows you to write applications like you would a desktop app. It has become one of the most popular projects on sourceforge and has been nominated for a 2006 Sourceforge.net Community Choice Award.

Recently I talked with one of ZK's creators, Tom Yeh of Potix, about the Framework's popularity and future.

ZK Background

DK: How did you come up with the idea for ZK, i.e. an AJAX framework that allows you to write webapps like you would a desktop app?

TY: As I mentioned in http://zk1.sourceforge.net/faq.html#Why, it is the result of frustration.

I was a fan of thin-client computing since leading a wonderful team to develop Network Computer and Window Terminal in 1995. I truly believe in the so-called utility computing. Accessing applications should be as simple as using tap water.

It is crazy that someone should carry tons of water when traveling, since tap water is available everywhere. However, we still travel with notebooks, even though Internet connectivity is everywhere. Similarly, the Web edition of MS Outlook has been available for years, but we are still using the desktop version. Why? Frustrated user experiences and excessive development costs. In other words, it is too costly to develop a Web UI from scratch or add-on to 'legacy' apps, and people won't use the Web UI even if it is provided.

After trying different ways to apply Ajax in the projects on which we consulted, we found that applying Ajax at the client side, as most frameworks did, only solved the half of the problem -- though it did result in a lovely interface. That is why ZK was born.

DK: Who is Potix?

TY: Potix is a consulting firm providing expertise in Web development and project management. We also develop applications on an ODM-basis. ZK is the consequence of this work. However, due to strong demand, we mainly focus on ZK now.

Potix is also a house of old dogs. Most of us have more than 15 year of experience, ranging from developing Windows/Linux/Web applications, to embedded OS and GUI frameworks. ZK is my second OSS project; the first one, called OpenPam (GUI for embedded devices), was not very popular.

DK: How are you planning on making money with ZK? Nextapp, the makers of Echo2, sells an Eclipse plugin for around $400. Is that a business model you are examining?

TY: Dual license (as MySQL did). You might also take a look at one of my posts: http://sourceforge.net/forum/message.php?msg_id=3605162

Other Frameworks

DK: Echo2 seems to be the only other server-side AJAX framework out there. How would you compare yourself with Echo2?

TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers.

Markup languages, like HTML, XUL and XAML, scripting languages, like PHP and Ruby, and the object oriented approach are the three most important developments since GUI was introduced. Unfortunately, Echo2, WebOnSwing and similar frameworks only focus on the object-oriented approach.

In addition to BeanShell, we are looking at the possibility of using Ruby and PHP in zscript. It looks to be, so far, quite feasible.

DK: There's lots of talk now about the Google Web Toolkit. Do you see it as a competitor to ZK or a complement?

TY: Both.

From a technological viewpoint, it is a complement. GWT is a client-side solution and quite good for developing Ajax components. On the other hand, it is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading huge JavaScript files into the client and executing them there is not fun at all. At the end, you need a server-side solution to handle the business logic and presentation tier.

It would be great if we can leverage GWT's power to simplify the effort of component development (as we did with DOJO and FCKeditor).

From a perception level, users might see it as a competitor. Google is now at a sweet spot with plenty of resources and a good reputation, as Microsoft was in the 1980s. Developers love to explore any kit Google puts out there and exaggerate what it can do as if Google was the first to invent it.

DK: Do you envision developers writing ZK components using GWT?

TY: Sure, GWT does a good job for non-JavaScript programmers who want to develop Ajax components. I expect that some results of this will show up in next few months.

However, what makes Ajax programming difficult is not JavaScript itself. Rather, it is the incompatible and buggy API (to communicate with DOM). The ability to do Java-to-JavaScript is important, but I am also hoping for some benefits from the standards efforts of OpenAjax.

The true value of ZK is its architecture. We look forward to adapting components to ZK as decent (client-side) Ajax components become available.

DK: What other AJAX tools, frameworks or technologies do you think are noteworthy or interesting?

TY: DOJO has an amazing set of components, though it is too heavy (one of the reason we didn't build the ZK Client Engine upon it). Atlas has great integration with Visual Studio. Anyone who wants to provide an authoring tool should take it as an example. Google Spreadsheets is an excellent Ajax application. You should unplug the network connection and see how it reacts, though. It's cool nonetheless.

Strengths and Weaknesses

DK: What would you say are the strengths and weaknesses of the ZK framework?

TY: Strengths: boundless. But seriously, great richness and excellent productivity, if we can put in a sentence.

Many of ZK users appreciate that they can design a rich Web application without programming. Many have thanked us for the intuitive event model and feature rich components that have saved them countless hours. Many enjoy the power of prototyping so they can change the look and function right in front of their customers. For more information, you could take a look at the executive summary (http://zk1.sourceforge.net/wp/ZK-exesum.pdf).

Weaknesses:

1. Stops working if the connection is broken. It would be better if a subset of functions still worked (such as read only viewing).
2. Round-trip latency, though hardly observable. To minimize the effect of this, we plan to, in addition to Client Side Action, add visual effects that execute solely at the client and notify the server only when necessary.

One other weakness shared by all HTTP-based solutions is the lack of Server-side push. Though someone has implemented so-called "reverse Ajax", it introduces too much overhead on the server. This -- server-side push -- is the next important step beyond Ajax.

DK: There aren't any production applications out there using ZK. Do you see that as a problem and, if so, what are you doing to address it?

TY: According to the profile of our customers, adopting ZK is still in the development (and evaluation) phase. By and large, adopting Ajax for most companies is still in an early stage. It is just a matter of time. I'm not really that concerned about it as long as the growth of ZK's acceptance is strong.

DK: Right now, the framework doesn't seem to allow for easy customization of the look and feel (window color, font, etc.). First, is that correct and, if so, do you have any plans to address it?

TY: Not correct. The look and feel are well separated by CSS and molds. What prevents users from customizing the look is the lack of documentation and samples. Also, the customization of the sophisticated components is sometimes not intuitive. It forces users to look at DSP files (the templates used to generate HTML tags). We realize this is an issue and we will provide documentation in the Developer Reference guide.

DK: I've noticed in the code that you spawn another thread to handle events. Can you explain the design to me? Also, how does this fit in with the Servlet standard and doesn't this make it difficult to cluster a ZK application if the user session has non-serializable information and context?

TY: It is common that an application has to confirm with users about, say, whether to delete a file. It is unbelievably costly for Web developers to implement such functions. Why? Users get no response until the servlet has completed, while the servlet requires user's confirmation to decide whether to proceed further.

There are many solutions to this problem, but the most elegant one is modal dialogs. ZK is one of the first Web framework that really enables the server-side modal dialog. The magic is to process events in another thread. Then, users can suspend and resume the processing anytime they like -- including but not limited to modal dialogs.

It does make clustering difficult if there is a pending thread in a session. We are working on the serialization issue now. A basic idea is to send the application a notification, and it can decide how to handle pending threads. Of course, if there is no pending thread, there is no notification at all.

DK: What is your favorite ZK feature?

TY: Macro components, the threading models, and zscript.

DK: Are there some cases where you wouldn't use ZK to develop an AJAX-based web application?

TY: Hard to imagine unless clients want the application to be functional even if the connection is off. Oh, action games, but it might not be a good idea to use Ajax there at all.

DK: It doesn't appear that you are using JUnit in the ZK code. Is this true? And if so, why?

TY: Only common utilities are tested with JUnit (refer to pxcommonTest in SVN). I am still thinking about which is the best way to test ZK components. We will come out with something in the near future.

Future Plans

DK: What is the biggest feature enhancement request you are getting from the users of ZK?

TY: Safari support and design patterns. By design patterns I mean information on how to really write an application with ZK. An illustration with Pet Store is a common request.

DK: On your road map you mention plans to provide a mobile version of ZK. First, what is the time frame for this? Second, how are you planning to do this architecturally? Can users write one application and dynamically re-target their apps to a different front end?

TY: We originally planned to provide a J2ME-based client engine, but we are keen on developing a Flash-based solution now. Architecturally, we have to do three things to support a new client: client engine, server engine and components. Users have to do two things accordingly: use a different set of components and adjust their UI to fit into small screen. We will keep the component API very similar (and also provide common interfaces that make developer's code polymorphic).

It is possible to let users use the same set of components, where components would be smart enough to detect the client and behave differently. However, we're not considering this approach because it makes the development and maintenance of components too complicated. Of course, we can use the factory pattern to chose the correct implementation, but it makes the instantiation of a component too complex for most users.

DK: You've stated that ZK is at the interface layer. Do you plan to introduce components that punch through to the data layer, sort of like the .NET datagrid?

TY: Yes. We will add more data-layer utilities, such as zkplus's DelegatingVariableResolver, too. After all, most ZK applications will have to access a database. However, we may not do a similar deep integration as Ruby on Rails did -- I don't like to make so many assumptions about how applications might be built.

DK: What do you see as the major challenges facing the AJAX community today?

TY: There are too many frameworks, such that many users prefer to wait. There isn't even a well-recognized categorization for them (such as server vs. client). A comparison chart or something similar would be very useful.

A standard like OpenAjax will help (at the client side), but I've never seen an alliance really work.

DK: Care to share any other plans you have for ZK?

TY: We are interested in adding mega-components, such as spreadsheet, forum and wiki. Part of the success of PHP is because the availability of plenty of off-of-shelf stuff. We won't develop all of these components ourselves. Rather, we prefer to help other developers deliver them either as OSS or commercial components. We will have a ZK.forge website to promote such collaborations.

Ajax Forms - Enhancing the user experience

The web is filling up quickly with examples of Ajax powered sites that allow us to do things we’ve never been able to do before on the web. From note taking apps, to spreadsheets, photo editors, and online games, Ajax apps like these are continually pushing the boundaries of what is possible, and in the process changing the way we work live and play on the internet.

However, we can also use Ajax to build better user experiences for the tasks we’ve already been performing on the web.  One kind of task crying out for Ajax attention is form submittal, in which a user fills in a set of fields and presses the submit button. 

Almost all forms today use the POST action in the SUBMIT button to upload data to the server, where processing gets done, and an entirely new page is sent back to the user.  Depending on the results, this might be a “Thank You” message, or it could specify an error in the form submission (more likely when the form is lengthy).  Either way, the experience is a poor one. 

First, the navigational requirements are increased, as at least two pages are required-one for form and one for result.  The result page usually contains no more that a couple of sentences displaying the results of the form submission, and possibly instructions on what next steps to take.

Second, the user has to wait until the end of the form submittal process to receive any error messaging.  This increases the likelihood that there will be unnecessary typing and mouse movement/clicking, since incorrectly entered information into one input field may require a user to reenter fields down the entire form. 

By using Ajax to asynchronously send the information to a server for processing, form entry and submission can be much more quick and painless. 

Information can be uploaded processed and returned as the user enters data into an input field.  Since not all the input needs to be sent at one time upon submit button on click, the user is told instantly, say, that the username he just entered is already taken.   

Once all the required form data is submitted, the result can be displayed on the same page, allowing the user to move on to other, more enjoyable, tasks more quickly.  If the form is small, and shares screen real estate with other content on one page, the user can continue on that page after the form is successfully submitted.  No need to hit the back button.

Here is an example of what can be done to build a better Newsletter Signup form.

Ajax continually provides us with new and exciting web based products and services.  But is also is a powerful tool for restructuring the way information is presented and manipulated on the web.

CMS and AJAX

Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:

If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.

So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,

Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.

Improve or die, I guess.

The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."

That's It?

The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.

I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:

• Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
• Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
• Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!

The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.

 

Example GWT App - Newsletter Signup

I decided to try out GWT on a simple project: providing a small newsletter signup box on a conference micro site. The idea was that after checking that a valid email had been submitted -- and complaining with a DHTML popup if it wasn't -- that email would be sent to a backend web service (asynchronously, of course). While the async XHR request was percolating, the newsletter box would display a thank you message, then fade away. A cookie would also be set, preventing the newsletter box from displaying during the lifetime of the browser session.

This just barely qualifies as AJAX, since I'm doing just one crummy little "Hello World!" communication with the backend. Still, it gets rid of the whole painful navigation to a signup screen, so that's a win in the AJAX column.

OK, so just 150 lines of code later (yeah, I know), I have my little box. The site is software500.pathf.com where you can see the newsletter box in the bottom right corner. Please be kind and don't sign up your goofy friends.

 

A few lessons from the excercise:

• GWT doesn't remove the need for Javascript. I found myself writing a few funky methods like this:
  

   public native void setCookie(String cookie, String value) /*-{
      document.cookie = cookie + "=" + escape(value) + ";Path=/";
   }-*/;
          
   public static native String getLocationHref() /*-{
      return $wnd.location.href;
   }-*/; 

• The GWT documentation is not complete. What is does talk about is pretty solid, but the fact that Google is not a shrinkwrap software company is pretty evident. Let's hope they hire some gifted technical writers and such for the general release of GWT.
• Debugging in the hosted mode is pretty handy. Not that an application of this simplicity needed a whole lot of debugging.
• One of the gaps in documentation is that it isn't very task based. Suppose you have a question like "How do I include a third party jar file?" You can dig through the documentation site and maybe come accross an explanation of the syntax of the MyApp.gwt.xml file and on another page the directory structure of a GWT project. Putting the two together takes a bit of noodling. That's definitely a steep start to the learning curve that doesn't need to be there.
• Spend some time with the more essoteric parts of the documentation, like how to write modules. Also, take a spin through the gwt.js file and see how it parses the gwt meta tags. This will ease your pain down the road when your GWT app and html page sit in different directories.

In my previous article on GWT Developments, I've pointed out several good resources for getting started, including the GWT newsgroup. Make liberal use of them.

AJAX and the Zeigarnik Effect

My colleague Bob Moll over in the UXD blog writes about the Zeigarnick Effect and it's implication for designing GUI's. What is the Zeigarnick Effect? Bluma Zeigarnick was a Russian psychologist who in the 1920's discovered that we remember unfinished tasks much better than completed ones. This memory comes from a psychological pressure to complete unfinished tasks.

Bob notes that in a rich GUI, the psychological pressure is to detour and finish short tasks, leaving a trail of longer, unfinished tasks. He suggests that we include a facility for a queue of unfinished tasks in applications so that users can easily go back and finish them.

In the web application world, we avoided this aspect of the Zeigarnick Effect by making it difficult if not impossible for the user to diverge from the page flow. Now, with the capability to use fancy modal dialogs that interact with the server, we can add optional subtasks into the flow. AJAX-powered command completion helps prevent the the user wandering off in another window to search for the right thing to enter. My favorite example is the WSJ's selection-based search, which avoid interrupted reading to search for another term.

As you design your applications, give some thought to the Zeigarnick Effect and how you can use AJAX to smooth the continuation of interrupted tasks.

MVC and RIA - Learning From Desktop Apps

Whether you're writing AJAX applications using enhancements to existing webapplication frameworks or adopting the new component GUI approach, you as a developer are faced with a new granularity of events. Where before you had the monster postback, now you must respond to mouse clicks, key presses, menu selections, etc.

On top of this, with a single page interface, you may have many more controls on the page. This brings on the problem of context, i.e. that not all of these controls are appropriate for a particular context such as when a particular part of a table or list box is selected or when the focus is on a particular window.

The above just scratches the surface of the sorts of challenges that you'll discover writing RIA's with AJAX technologies. The good news is that there are already solutions in place since these are the sorts of problems that desktop GUI developers face all of the time. For example:

• Enabling and disabling menus and other controls can be done using the State pattern. A collection of state objects would be used to enable and disable the controls as appropriate.
• Many of the component GUI frameworks implement an Observer pattern for event management. UI events come in now in little bites instead of one huge request and can be consumed by listeners that wait on a specific component.
• MVC needs an upgrade when you're dealing with big heirarchies of components. Combining the Composite and Chain of Responsibility design patterns, you get the Heirarchical MVC (HMVC) pattern. (If you've worked with WebWork you may have run across the "Pull HMVC" pattern. That heirarchy refers to the model, not the whole MVC.)
• The Command pattern is often used to implement undo.

That's just a sampling of desktop GUI solutions you can make use of. What can you do to expand your solution space for RIA's? Read lots of code. Find as many good open-source desktop GUI's as you can and read their code. You'll find ways of doing things that don't resemble the typical webapp approach. Here are a few to get you started.

Resources:

• The Spring Rich-Client Project. Based on the Spring Framework. Used for buidling desktop GUI's. Read the code and get a sense for how to build your RIA framework. Good source for ideas

• HMVC framework and tutorial. View/Implementation independent. You can plug this into your own apps or just learn from it.

• The Scope Framework. The bad new is that this is a desktop GUI framework based on Swing that hasn't been updated since 2002. The good news is that this is a great place to read some code and learn how to develop component GUI applications.
• The HMVC Framework from Crionics. Again, no longer maintained, but a great place to read some code.
• Tutorial (in C#) on implementing undo with the Command pattern.
• A discussion of the Presentation-Abstraction-Control (PAC) architectural pattern. This one is just as old as the MVC pattern, but since the MVC pattern was intended for simple interfaces it was also simpler to implement. Thus MVC won out even in cases where PAC is more appropriate, such as with more complicated UI's.

Update 1: Oliver Steele has an excellent overview of MVC as it exists in the desktop, webapp and RIA worlds. He points out why non-RIA, i.e. traditional webapp programming is so tough:

That complexity includes the real world application of what are still research topics in academia: staged programming for multiple-target code generation (Mac IE, Windows IE, Netscape, Mozilla, Safari, Opera), process migration, and (usually manual) CPS conversion to maintain program state across pages.  No wonder web programming is hard!

Well worth a look.

Direct Manipulation Interfaces, Document-Centric Applications and 7 More Reasons to Use AJAX

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.

UML Modeling in the Browser

There have been some interesting experiments in breaking the bounds of the rectalinear forms-and-reports browser interface. One example,  John Resig's dModeler, is a cut at a UML class modeler. In his words it is:

A web-based UML modeling program that my team wrote for the 4th Red Bull Programming competition. We weren’t able to complete all that much of it, but we did get creation of classes, links, drawing, signups, logins, and parameter creation finished. At some point it may be fun to sit down and modify what we wrote and get it fully operational and possibly release it.

There's no AJAX logic behind it to provide any logic or even persist it, but I encourage folks to look at it that you can provide rich client functionality in the browser. Think outside the grid.

Update 1: you may need to use Firefox to get this to work. Ironically, it was designed to work with IE, but the login has some Javascript errors. Firefox will blissfully ignore the logins and get you to the diagram.

A Useful Resource: Ajax Pattern Wiki

Michael Mahemoff's Ajax Patterns Wiki is more than just about patterns. There's a bunch of information on frameworks, tutorials and examples. But if you have a taste for design issues and general, repeatable solutions for solving them as they apply to Ajax (i.e. a design pattern), then this resource is for you.

Patterns are divided into several categories: Foundation Technology, Programming, Functionality and Usability. There are 62 patterns in all, along with some development tips and practices (testing, logging, etc.). Some of the patterns are empty for now, such as the "Multithreading - Use a timer and a worker queue to process jobs without the blocking application flow" pattern.

Some of the patterns are a little light on detail and might be termed more "good ideas when implementing Ajax apps," but they are nonetheless useful. The "real life examples" sections are particularly valuable.

Ajax and the "Back" button II

Designer's (of which I am one), are beginning to wrestle with the consequences of implementing Ajax, Flash and other rich interface technologies on the web. 
Among those consequences, is what to do with the "Back" button. It alone is responsible for almost 50% of web user clicks on today's web.  However, it can lose its usefulness--In fact become somewhat of an obstacle-- on sites powered by Ajax, Flash, and other Rich interface technologies. 
Mike Stenhouse of Content With Style believes that the back button is too important not to spend significant design and development time making certain it functions properly on Ajax web apps.  Without it...
The most fundamental online behaviour – click then back, is broken.
and sites become irritating at best, downright unusable at worst.  Ensuring that Ajax, as a web standard fails.  More here

What the Commodore 64 can Teach Us About Ajax

Here's just a little sampling of articles from the November 1983 issue of COMPUTE!'s Gazette.

• Computer Graphics - The Age Of Electronic Art
• VIC Super Expander Graphics64
• Introduction To Custom Characters For VIC And 64
• VICreations: Animating With Custom Characters

It seems every issue would have at least two articles on how to twiddle the graphical bits on the C64 or VIC-20, articles on how to make sprites dance across the screen or writing your own video game or drawing program in 6502 assembler. You had similar articles in similar magazines with the introduction of the IBM PC.

With the advent of the Mac (yes, yes, Xerox did it first), all that bit twiddling disappeared. People started wondering more about how to get windows and menus and buttons to do what they wanted them to do, or even to start developing their own controls.

Fast forward almost 23 years and read just about any blog or magazine that features Ajax articles. The articles are almost universally about nuts and bolts, nitty-gritty details, i.e.:

• Writing a server-side Ajax handler
• Creating souped up popup windows with Javascript
• Implementing fancy form controls in Javascript
• Understanding the DOM

It's bit twiddling all over again. Perhaps it's time to write an article on how to do Sprite animation with Javascript.

DO NOT PRINT THIS FORM

A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company's Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.

I'm sure most people involved in systems development have experienced this sort of infuriating situation -- I've seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I'm not alone. No matter how much testing and training is done, some people can't get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.

In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn't play nice with the application design. You ended up doing lots of kludgy things that you wouldn't do in a GUI or command line application. You had to think differently in order to build successful web apps.

As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we're missing an opportunity to rethink how we build webapps. Isn't it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don't depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let's rethink and DO NOT PRINT THIS FORM.

Ajax and the "Back" button

Among the issues that the increasing ubiquity of Ajax on the web brings up is, where does that leave the "Back" button.  Or, is the page metaphor still relevant, and if not, how soon before everyone knows it?   
Essentially all worthwhile new technologies ask us to change our understanding of the domain they effect, and the compilation of techniques together known as Ajax have the potential to do just that.  But it will take time, no doubt.  There's still a lot of work to be done--both for developers and designers--before adoption becomes universal, and years more before the inevitable breakdown of the page metaphor.  On the way, questions will need to be asked about where we as web app developers see our role in the transformation to "Web 2.0".

Why Frameworks are Important

I've been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it's useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM's Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.

A framework exhibits "inversion of control" at runtime via callbacks. These callbacks invoke the hook methods of application-defined components after the occurrence of an event, such as a mouse click or data arriving on a network connection. When an event occurs, the framework calls back to a virtual hook method in a preregistered application component, which then performs application-defined processing in response to the event. The hook methods in the components decouple the application software from the reusable framework software, which allows each to change independently as long as the interface signature and interaction protocols are not modified. Since frameworks exhibit inversion of control, they can simplify application design because the framework—rather than the application—runs the event loop to detect events, demultiplex events to event handlers, and dispatch hook methods on the handlers that process the events.

Inversion of Control, it's not just for Spring anymore. :-) Seriously, though, how many of the current Ajax toolkits -- I'm not sure that with the exception of appfuse it's correct to call them application frameworks -- give you IoC? I'll be watching to see if they make the transition to frameworks and will give credit where credit is due.