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.
on December 13th, 2005 at 10:35 am
Tagneto’s View Assembly tool (http://tagneto.org) might address some of what you want to accomplish: allowing web designers to use a declarative language to build the UI, but allow that UI have rich DHTML/Ajax capability. (Disclaimer: I develop Tagneto.)
The View Assembly tool allows for replacing plain HTML elements found in the source with other HTML/CSS/JavaScript. New tags can be defined too that encapsulate a set of HTML/CSS/JavaScript to include.
You could define tags for your Zimbra AjaxTK widgets to give UI developers an easy wrapper for the widgets. If you wanted to override all button elements with your own custom button widget, you could do that too.
It works well with existing source. You don’t need to modify the source to run it through the View Assembly tool, just provide a separate XML configuration file that tells the tool what tags to process. The HTML does not have to be XML conformant (but the tags to be processed have to match one of the supported syntaxes). It is a developer “compile-time” tool: it should be run offline, before pushing the code out to the web server/application server.
Because it runs offline and it only processes tags/syntaxes that you define in the configuration file, it plays nice with PHP/ASP/JSP code.
on January 5th, 2006 at 2:27 am
I have come across the same problem, in my company AJAX is currently being driven forward by developers, so thought to how the designers are going to use this in collaboration tends to be forgotten.
I have been using hidden div tags to define templates, so that dynamic sections of the site can be written in Dreamweaver, and the JS writer just has to look at the .innerHTML of the div and do a string replace on VARIABLE names.
on January 9th, 2006 at 12:00 pm
Hiya,
I was really excited when I read this on Ajaxian. Yea! someone in the greater AJAX community finally speaking about “Design”. Then I got here to some huge disappointment.
First off, I think this article is great for the developer/engineering community and it is right on track that tools and services need to be made to enable lower-level technicians use AJAX. I think this was done really well by Dreamweaver for example when they incorporated basic JS scripts/Behaviors into the core of the application and I can imagine that in version 9 of studio they’ll do the same thing. I know this isn’t a very Open Source option, but this community is NOT an Open Source community right now, no?
Ok, now to my real point. What I was hoping for when I got here was really an AJAX for Designers. Real designers (interaction design, GUI design, InfoArch, User Experience).
There have been some attempts to create patterns for AJAX at http://ajaxpatterns.org and I also wrote a piecee called AJAX for Designers which you can get from http://synapticburn.com/comments.php?id=97_0_1_0_C
When I speak of design, I mean to say how to use the technology, not from a programatic perspective, but from an application standpoint. Where, when and why to even use it, and what can it offer. These are important issues that the design community including the community you were trying to address need to understand. Usabiliyt is another huge concern, as well as accessibility.
on January 9th, 2006 at 12:01 pm
Yes, thank you for thinking of and about people who are not programmers by trade or hobby, for whom Ajax is well-suited.
Some of us don’t have enough time in the world to really learn/understand how to use Ajax, even though we understand it in principle/concept.
Also, unfortunately, most Ajax demos/examples are trivial things like sliding windows instead of real things that real people and websites can actually USE.
Until Ajax becomes available with better tools and useful examples, it will be for programmers only.
Thank you for reading this, Tom
on January 13th, 2006 at 1:44 am
Imho UI should be HTML + additional xml tags + REST url. See http://www.zimbra.com/blog/archives/2005/11/all_rest_and_no.html
So you define a grid like a HTML table + href
<grid href=”http://server/zimbra/user/roland/calendar” width=”100%” />