20 people voted for the css design contest runoff. Of those, 3 people voted after the Tuesday midnight deadline. Here's the final winners of this contest:
- 1st place: puzzlewithstyle by Mattias Fjellström
- 2nd place: andreas01 by me (the question is: should I win or Andreas Viklund - the original designer?)
- 3rd place: simplicity by Herryanto Siatono
The 3rd place winner was a close call: deliciouslyblue tied with simplicity, but 2 votes came in after the deadline. Congratulations to all the winners - and thanks for helping out with this contest.
Since I'm traveling in San Francisco this week and next, it'll probably take me a couple weeks to send out the prizes (iPods) to the winners.
Now for hard part: integrating the entries into AppFuse for 1.9.2. I hope to make all the winners AppFuse-compatible and ship them (or make them downloadable) as part of the release.
Scott Dietzen is the former CTO of BEA. Apparently he was one of the original founders of WebLogic, before it was bought by BEA. Scott's hope tonight is to share his experiences from developing Zimbra. Why does Zimbra use JavaScript and Ajax?
- Richly interactive UI
- Rich client/server communications
- Zero-cost administration
- Web security
- Web look and feel (back button and bookmarks)
- Multi-browser "standard"
All of the above features where things the Zimbra team expected. They also got lucky in a number of areas.
- SAO/Mash-ups and Ajax authoring
- RIA winner? Big sites voting with their feet: Google, Microsoft, Yahoo, Amazon, etc.
- It really works
They started building Zimbra 2.5 years ago, long before Ajax was possible. Scott actually tried to talk his team out of using JavaScript when they first started architecting the application.
Zimbra's tools are good for Java programmers. If you're not familiar with OO concepts, it might be a bit difficult to understand. Now Scott is showing some demos, basically grids and trees - all built using the "Zimbra toolkit", whatever that is. Now he's moved on to demoing the Zimbra application itself. I used Zimbra as my primary e-mail client for a couple weeks and it's by far the best web application I've ever used. Not only does it look awesome, but everything works just as it would in a desktop application. The unfortunate thing about Zimbra is it has two licenses: an open source one and a pay-for version that has all the features you really want.
Zimbra = "Pure" Ajax. All UI behavior specified in JavaScript. The *entire* UI is written in JavaScript, no HTML. It's more like a typical GUI application from a programming perspective (think JavaScript SWT). Result is "husky" client 3-tier architecture. All UI on client, server-side Java code for UI operations. This is very different from HTML "design center" where you start with an HTML page and augmenting with Ajax. The Zimbra toolkit actually doesn't fit very well into most applications, where folks enhance HTML pages. It's more designed for programmers who want to write their entire application in JavaScript.
Ajax is finally giving us a clear partition between client logic and server logic. The dividing line is up to the developer, that's the challenge for web developers today. It's basically a user-defined SOA Endpoint. Before Ajax, in the Java world, JSPs and Servlets were considered the client-side, even though they were really more server-oriented.
Ajax applications are cheaper on the server/network than Web 1.0/HTML apps. Modulo the initial download (gzip is essential). Ajax is much more expensive on the client CPU. Tend to be finder grained in their client/server interactions. They tend to be more stateful. Rule #1: Pick your service bindings well! For modularity and re-use/mashups.
"There's a special place in heaven for whoever had the patience to get all of that JavaScript right." - Paul Ambrose, WebLogic Founder on Zimbra
Ajax Challenges: Browsers and Toolkits. Browsers render the same HTML differently, they have different event models, different levels of DOM supported, they have different APIs that do the same thing, as well as many issues. As far as toolkits for Ajax, there's too many rather than too few. Consolidation would definitely be a good thing.
Zimbra's Ajax Tookit (AjaxTK), Apache Kabuki* is modeled after SWT. It's a JavaScript OO class library and open source (Mozilla or Apache licensed).
Another big challenge is lack of integrated tooling. There's lot of technologies to deal with concurrently: HTML, CSS, JavaScript, etc. The initial stab at a solution is the Open Ajax Initiative. This is largely a set of technologies from Eclipse, Mozilla and Apache. There's 30-odd companies involved with the initiative, including: IBM, Zimbra, Eclipse, Firefox, Apache, Google, Yahoo, Oracle and Red Hat (or at least that's the logos Scott has on his slides).
The proprietary Ajax Landscape consists of MS Visual Studio (Tooling) and MS Atlas (Toolkit). On the open source side, there's Eclipse+Mozilla for tooling and all kinds of frameworks for toolkits (i.e. Zimbra/Kabuki, Dojo, Scriptaculous). Scott's opinion is there's really no room for any proprietary vendors to provide solutions outside of Microsoft.
Now Scott is doing a demo of mash-ups in Zimbra. He's showing how you can mouse-over many things in an e-mail message to get the information you're looking for w/o switching to a new page/context. Mash-ups he showed include: real-time flight information, displaying schedule for a particular day, dragging a message to an SMS sender, viewing a map by mousing over an address. The latest thing they're working on is dragging an appointment from a calendar to a "travel agent" that books your flight.
Zimbra also includes a WYSIWYG authoring environment for documents. It allows you to do HTML editing (in design view) as well as embedding spreadsheets within pages.
Zimlets: extensible mash-ups for e-mail, calendaring, IM, etc. They're a merge of "pull" and "push". There's zero-client install and they're secure because they're managed by the server administrator. To create a Zimlet, you develop a declarative XML template (Regex, ActionURL, XSLT, CSS, Menu). JavaScript can be used to override Zimbra client-based classes. JSPs can be used on the server-side for customization. Ajax Linking and Embedding (ALE) is Ajax components that are embeddable in editable HTML (simple docs, spreadsheets, etc.). Views are read-only HTML and WYSIWYG Ajax authoring (Ajax cod is the "authoring" application).
Practical Tips for Ajax:
- Use an Ajax toolkit
- CSS is your friend
- Use JSON (as well as XML)
- Use asynchronous network programming
- MVC paradigm worked for us
- Tooling better, but rough edges remain
- _all.js -> jsmin (saves ~ 1/4X)
- _all.js, _all.css -> gzip (saves ~ 3-4X)
- Mercury's QuickTest-Pro (QTP) [IE + FF*]
- Pick your fights - not all applications need to be Ajax enabled
- No such thing as secure client-side business logic in Ajax
- Dedicate some top UI OO talent (or wait for tech to catch up)
Ajax Sweet Spots:
- Richly interactive UI desirable (HTML simplicity is ideal for many applications - for example, you'd rather use Amazon's one-click than drag a book to a shopping cart)
- Combine with web look and feel and deployment
- No client-side data/resources (but is changing, stay tuned)
- Perfect for on-demand services
Recipe for Ajax Success: Ajax is not a business model, compelling and appropriate innovation is essential.
Next Ajax Steps: In open source land, try the OSS toolkits, Eclipse ATF and participate in Ajax communities (Apache/Zimbra, Eclipse, Mozilla, Dojo, Scriptaculous). Scott moved to fast for me to catch his recommendations for Microsoft developers. He did have positive things to say about Microsoft though.
Hardest Ajax problem of all? Recruiting. According to Scott, it's incredibly hard to recruit people that know Ajax.
Update: Additional coverage of this talk is available at Ajaxian.com.
After Patrick's talk this morning, I attended Alex Russell's talk on Dojo in depth (download presentation, blog coverage). I didn't write up a blog post because the juice was gone on my laptop. After plugging in, I checked my e-mail to find a message from Patrick in my inbox.
Subject: At the giants game
Sucka! If you want to go, my buddy has two extra tickets just sitting
here.
So now I'm at the game, using their free wifi to write this post. It's a beautiful day - warm in the sun and cool in the shade. We're in the shade, first level by first base, and I'm drinking a beer. Giants are up 9-0 over the Cubs. Life doesn't get any better than this. 
I'm sitting in Patrick Lightbody's presentation on Leveraging AJAX in modern web frameworks. The point of this presentation is to give a preview of what's coming in Struts Action 2.0. There are a number of other good sessions I'd like to go to, particularly Intro to Dojo, but I figured it's better to attend this talk since AppFuse will be moving to SAF as part of 2.0. We're in a fairly small room, and there's about 20-30 people in attendance. With 400+ people at this conference, the other sessions are likely packed.
Ajax is more of a technique, rather than a technology. Commons Ajax techniques include:
- Tabbed pane
- Validation
- Polling
- Tree widget
- Voting
For SAF, there are three core building blocks/tags: <saf:div/>, <saf:a/> (results evaluated as JavaScript) and <saf:submit/>. Divs are where things "happen" and links/submit buttons can trigger events. There are two frameworks used is SAF:
- DWR: Remote invocation service for Java <-> JavaScript
- Dojo: Language/server-agnostic JavaScript framework
There are two styles of Ajax: DOM manipulation (DWR) and partial pages (Dojo). SAF provides three Dojo widgets: BindDiv, BindAnchor and BindButton. The div tag supports the following attributes: href, updateFreq, delay, loadingText, errorText, showErrorTransportText, listenTopics and afterLoading. A simple example is polling - where the remote action returns HTML:
<saf:div href="mailbox.action?id=%{id}" updateFreq="2000"/>
Advanced usage of this tag includes adding a <script> block to the returned HTML. It will be executed when rendered, just like normal JavaScript is.
Tabbed pane is another component that's made up of two tags: <saf:tabbedPanel/> and <saf:panel/>. Rather than specifying content/tags within an <saf:panel>, to use the Ajax version, you simply add remote="true" and href="remoteUrl" to <saf:panel>. I asked about remote="true" being redundant and Patrick agreed it should be implied when an "href" attribute is defined.
SAF also includes the ability to have topic-based events. Dojo supports an event system, which was originally donated by the WebWork developers. Any element, such as a div, may listen to multiple topics. Any element, such as an href or tab header, may notify a topic.
The last thing that Patrick is demonstrating is Validation using DWR. To use it, you will need to use SAF's Ajax theme, as well as have DWR installed and configured. The remote calls to SAF's validation engine return serialized objects rather than HTML "partials". By default, it uses onBlur events to do the validation and all that's required on the client-side is validate="true" on your <saf:form>. Another cool Ajax feature that SAF has is an OGNL Console that gives you a command-line interface to evaluate OGNL expressions.
Patrick's lessons learned from implementing Ajax into WebWork/SAF:
- Simple combinations of the basics can create powerful features, such as the tabbed pane or the tree widget.
- JavaScript inside an HTML block (<saf:div>) or as returned from an action (<saf:a>) can provide valuable glue code.
- The <saf:div/> and <saf:action/> tag have a close and important relationship.
- Understand the important differences b/w Ajax styles (DOM-based vs. snippet-based). Both have their places.
Pitfalls:
- Remember: there is no silver bullet
- At the end of the day, your application is still a web site - don't forget that
- Excessive polling can lead to extreme load and/or thread starvation
- Common functionality, such as the back button and printing, can become difficult or confusing for the user (Dojo can help solve this problem)
- Browser incompatibility can lead to two versions of the same application (see GMail)
The Struts Team hopes to release a preview release of Struts Action 2.0 this week or next, with a final release targeted for August.
When I first saw Mike Stenhouse's CSS Framework, I was very impressed. It's hard to believe it's been a year since I first saw it, and only now am I integrating it into AppFuse. It figures that the week I'm implementing it, Yahoo comes up with something better: Grids CSS. Thanks to Jacob Hookom for e-mailing me the link.
The features of Grids CSS include:
- Full A-grade browser support
- More than 100 page layouts with a single CSS file at just 1.82KB
- Flexible scaling with user font-size adjustments
- Min-width enforcement, regardless of font or viewport size (except IE; helper JS under consideration)
- Abundant DOM hooks for CSS and scripting flexibility
- Source-order independence, allowing you to place your most important body content first in your HTML document
- Self-clearing footer (no matter which column is longer, the footer stays at the bottom)
- Centering within the viewport by default
- Forward-compatibility as standard page structure evolves to claim more screen real estate
- Accommodation for IAB Advertising Units
This is obviously a better solution than the CSS Framework, especially since it seems to be well-documented and allows source-order independence. However, it suffers from a similar problem: there's a lack of good-looking designer-styled templates that showcase how cool this library is. There is hope though, Andreas Viklund (a well-known open source template designer) is talking about a Modular CSS Template. The question is: will he re-use Yahoo's Grids CSS or invent his own?
[Yahoo's Grids CSS] is almost exactly what I was working on - but much smaller and probably better than I would have done it. The main difference is that I added a few extra layers to the cake: Make-up (layout-wide styling for typography, forms, headers, links and so on), Colorscheme (just what it sounds like) and Backdrops (background images). Designers can add each layer separately. If you have a site based on the template and you want to change the styling - add a new Make-up. It is a matter of cutting and pasting blocks of code into the CSS, even a beginner with no CSS design skill can do that. If you want to use different colorschemes for different pages - just add more colorschemes and call it from the colorscheme class of each page. One line of code to change, and the effect is very obvious?
It's cool to see there's lots of work going on in this space. While AppFuse 1.9.2 will include the CSS Framework, there's nothing stopping us from using a different solution for 2.0. I'm leaning towards moving to Yahoo's solution, but it's likely I'll be heavily influenced by Andreas' work in this space. Of course, since Yahoo's library is open source, it might make sense for Andreas to simply contribute to this project and improve what they've already done.
