As it is realized within Zimbra and most other Ajax applications today, development is accomplished via GUI, object-oriented programming in Javascript. (Please see Ajax Programming Report Card and Ajax Sweet Spots.) This is the sort of work that developers with Java SWT, Java Swing, or C# skills will accel in at, but also the sort of work that will leave some Web designers (e.g., Dreamweaver or Frontpage users that have not dabbled in OO programming) scratching their heads. The success of technologies like PHP, ASP, and JSP is that they helped bridge the gap between UI “programming” and UI “designing.”
Something analogous is essential for Ajax success longer-term: Richly-interactive, lush Ajax applications are inherently harder to program even with open source widget toolkits (like Zimbra AjaxTK) and integrated tooling (stay tuned on the latter). In our experience, it takes depth in OO/GUI programming to deliver such a rich client. However, the reality is that Ajax UI components are often going to be sharing client real-estate with HTML content. (This is not the case with Zimbra, which relies upon Javascript and CSS rather than HTML to paint its browser UI.) In other words, the industry needs an evolutionary evolutionary approach (coexistence with HTML) to reach the Ajax “sweet spots” rather than a revolutionary one. To that end, we have been working out how to use the Zimbra AjaxTK for richly-interactive subcomponents of traditionally authored HTML content. This is essentially achieved by “weaving” AjaxTK components (such as buttons) into existing HTML content by reparenting the components’ enclosing HTML elements to the desired location in the HTML content (e.g. placing a button within a table cell).
Ultimately, we hope to see higher-level, and more declarative languages that can more easily be authored by Web designers, but nevertheless provide much (but perhaps not all) of the rich interaction capabilities of Ajax. And when you need to finely tune the GUI, you still have the option to drop into full-on Ajax programming. The age old adage “simple things, simple; hard things, possible” remains the mantra of choice.
We believe the best way to get there is to continue building bottom up:
1. Settle on a handful of Ajax widget toolkits and ensure they get to critical mass (Think SWT and Swing). We’re offering Zimbra AjaxTK as one such candidate, but the greater open source community is the final arbiter of winners.
2. Provide rich integrated open source tooling targeted primarily at GUI/OO programmers.
3. Define how to relatively easily augment existing HTML content (such as served by PHP, JSP, etc.) with Ajax subcomponents (that is, Ajax code would typically take over certain regions of the browser UI).
4. Experiment with higher-level declarative languages for authoring Ajax and HTML.
While (4) remains a future, we believe that the progress the open source community has been making on (1), (2), and (3) are necessary prerequisites to (4). Items (1), (2), and (3) enable Ajax technology to be successful applied to both new UIs (e.g., Zimbra) and augmenting existing HTML UIs. Item (4), on the other hand, is more critical if Ajax is ever to begin to displace HTML rather than augment it. We are still skeptical on the latter—after all, not all applications (unlike email & collaboration) need richly-interactive UI. Better to use Ajax for its sweet spots.
Comments are closed.