JQuery Widgets and the Widget Challenge
JQuery is rapidly becoming my favorite Javascript library. With it's ability to pack a complex operations into a single line, it sometimes feels a little bit more like Perl than Javascript.
JQuery allows for plugins, so you can build widgets and extensions on top of it that will work with one another. As of right now, there are already quite a few widgets and extensions built on top of JQuery:
Interface - large collection of plugin effects for jQuery, including draggable, dropabble, etc. A must visit site. Also includes a list of plugins developed by other developers (some of which you will also find in this post). Date Picker - standard date picker. JQuery Portlets - based on the above Interface plugins, a draggable portlet interface. Very slick.
Dylan Verheul's autocomplete, editable, autohelp and google maps plugins. PanView - drag an image around in a little view port. YShout - a shoutbox (allows users to chat on your site or page).I haven't seen a rich text editor yet, or the FishEye widget. The main jQuery site has an extensive list of plugins, including the above and more.
Feeling the pressure from Dojo, the JQuery guys have issued a challenge to the developer community to come up with new widgets based on JQuery:
Dojo released a new widget today: a spreadsheet widget. and it ocurred to me that while we don't quite have anything like that yet, there are scattered widgets throughout the jQuerysphere. I figured it'd be nice for us to put together a jQuery widget package that, to the extent possible, mirrors the Dojo widget set.
The challenge is this: where there is no existing widget, create it. The holy grail, at this point, would be a replication of their spreadsheet widget or their rich text editor widget.
I'd like to put together the widget pack at some point in the next month, and I'll be featuring the widget pack in next month's Magazine. Theere's nothing requiring an exact mirror of the Dojo widgets, so feel free to submit widgets that are not present in Dojo.
A little friendly competition is a good thing. I look forward to more JQuery based widgets being developed and Dojo following suit. While you're at it, check out the powered by JQuery button challenge. Winners get Ajax books. Cool beans. You can never have too many Ajax books.
Topics: Ajax Frameworks, Ajax Widgets, Announcement
Even Microsoft Needs a New Development Approach with Ajax
I'm sure you've all heard from various sources that the new Beta of Atlas has been released and that it isn't called Atlas anymore but ASP.NET Ajax. Lots of changes have been introduced, including the renaming of the $() function to $get() to allow it to work with other Javascript libraries. Maybe it's not quite Beta quality, says Rick Strahl in his recent post entitled More MS Ajax Pain. I have a hard time feeling sorry for Mr. Stahl, since he blogs from Maui, Hawaii, but I'm sure lots of other .NET/Ajax developers share his pain:
I've had one hell of a frustrating day going through my code and moving it to Atlas Beta 1. I'll get into specific issues in a minute, but my overall feeling is that this build is REALLY BUGGY. The previous ATLAS CTPs were reasonably stable and handled errors gracefully forwarding them to the client code. This build just crashes hard in many cases deep inside of client framework code. I've been at it for the better part of the day and while I managed to port all of the samples, just about all of them have one or two issues that I cannot seem to resolve completely without removing functionality. In fact, I've been doing that alot - skipping using framework features instead resorting to lower level JavaScript because it works.
Ouch! Rick goes on to detail the various specific issues he's had using the Beta. In my view, this isn't a fatal flaw in ASP.NET Ajax, just an early misstep due to the pressures to release something during this mad scramble to grab Ajax mindshare. The product and development process are still a little green and .NET developers and MS are feeling their way forward.
The truth is we're all still learning how to build, debug, test and support Ajax applications. See the various development tips from Ajax framework developers on how to debug applications festooned with Ajax widgets. New abstraction, inderection and other plumbing will make it easier to develop, but harder to debug and productivity is bound to go down before it goes up. It's been a long time since I've had any direct insight into Microsoft's internal development practices, but I have to believe they are struggling to find qualified Javascript programmers just like everyone else, just as I'm sure they're struggling to extend their unit, system and regression testing processes to cover the far more intricate logic on the browser.
At the end of the day, it looks to me that MS's approach of incrementally improving ASP.NET will be just good enough to allow them to capture the biggest market share for .NET Ajax. But TibCo GI, Echo2 (when the .NET version comes out), etc., all look to have more interesting offerings, IMHO, even for big corporate players who want to stick to .NET, especially if the productivity of their developers goes up.
Topics: Ajax Development, ASP.NET
That Giant Sucking Sound is Ajax Turning Your Site into an Application
I have a simple rule of thumb for support costs: take the number of use cases, function points or whatever you use to estimate development effort, multiply it times the number of users who will be accessing your application, correct for the sophistication of that population -- Joe Hacker versus Grandma Moses -- and the amount of money that is on the line for both your users and your company, and voila! you have a three shift operations center and an army of developers wearing pagers. Actually, it gives you an order of magnitude figure for the kind of effort supporting your application will take.
Here it's common to distinguish between sites and applications. By sites we usually understand the simple content display where your use cases consist of browsing, search, emailing an article to a friend and viewing an article in printable form. Four use cases, give or take. Add in the occasional submission form, and your support team, such as it is, barely needs to break a sweat. Applications, if I may state the blindingly obvious, have many more use cases and thus much greater support costs.
Now at what stage does a site become an application? This is sort of like the riddle of Theseus' ship. (Theseus was the guy who slew the Cretan Minotaur.) His ship was preserved as a memorial. As planks and other wood rotted, it was replaced bit by bit until not one piece of the ship was original. Was it still the same ship? If not, at what point did it stop being the same ship? Fortunately for us, our question is not quite as hard. Ours is not a question of identity but of degree. A site doesn't magically become an application with one additional use case, it just becomes more complex. In fact, our distinction earlier between sites and applications was a false one -- a site is a simple application, with a simple purpose and simple task flows.
Now I started this post talking about support costs and ended up talking about wooden planks. My point is that as you go about replacing the rotted postback planks in your site or application with nice new pressure treated Ajax planks, keep and eye out for feature creep. Are you adding functionality to your site? Are you adding digg style voting to your content? Are you adding a portal so users can customize their experience? I'm not saying don't add them. By all means, take advantage of the opportunities the technologies give you, just be cognizant of any new features and use cases you add. You could find yourself sucked from the relatively safety of the content application -- or "site" -- to the deep water of the full on application.
When they pry the support pager from you cold, dead hands, you'll go to that Valhalla that is home to optimists, jaywalkers, chronic underestimators, and managers that think that product launch is the finish line.
Topics: Best Practices, Editorial
Where is all the Prototype Documentation?
In the recent blowup between Prototype and JQuery, one of the self criticisms coming from the Prototype community was that there isn't enough good documentation of the framework. I don't think that's true. It's simply that the resources are just so spread out that it's hard to find them. Here are some of the resources I used for learning how to use Prototype. Maybe you'll find them useful too.
Of course you'll need some information on why not to use Prototype and what it's limitations are. That last is one issue I have with Prototype: there is no standard answer to the question "on the low end, which browser versions does prototype support?" More on that later.
Topics: Ajax Frameworks, Javascript
Clorox - Shared Memory Abstraction for AJAX Applications
Take a step back and squint and you'll see that Ajax, with it's ability to pass structured data back and forth between client and server, can be used to implement just about any architecture or abstraction that involves communication between execution environments. The only things getting in the way are the platform and performance limitations of the browser. Even with this limitation, we've already seen implementations from the obvious RPC (DWR, JSON-RPC, etc.) all the way to X11 (XML11) and various client engines and protocols in between (TibCo GI, ZK, Echo2, JackBe, etc.). If you haven't realized this already, there's more than one way to do things with Ajax.
Now along comes Clorox, a different kind of abstraction on top of Ajax. Developed as an MIT class project (see the paper here), Clorox hides all of the asynchronous request business behind simple Javascript data structure access.
In place of the asynchronous, RPC-based abstraction furnished by AJAX, Clorox provides the illusion of synchronously-accessed data structures shared between the web browser and web server, which is to say, it provides a shared memory abstraction. These data structures look exactly like ordinary JavaScript objects on the client side, allowing programmers to focus on what they do best (writing compelling web applications) without worrying about data locality, message reordering, callback functions, or data prefetching. Additionally, to free programmers from concerns over locking, Clorox allows multiple operations on these data structures to be grouped into atomic actions.
Clorox is a client-side technology. You have to write the backend code -- returning JSON objects with a TTL that controls caching -- yourself. Clorox consists of the Javascript runtime (which incorporates MochiKit) and a compiler (based on Rhino) that transforms application Javascript to Javascript. Why this extra step of compilation?
The Clorox Compiler compiles Clorox JavaScript files (.cjs files) into plain JavaScript. Didn't we just say that programmers write their applications in ordinary JavaScript, you ask? Yes, they do. However, under the hood, Clorox does have to make asynchronous AJAX calls to fetch data. The Clorox Compiler takes in JavaScript code that makes synchronous accesses to data structures and transforms it into JavaScript code that accesses the data structures using continuation-passing style programming. (This means that every time a data structure is accessed, we supply a method that indicates what to do after fetching the appropriate element). Essentially, this involves breaking up the code into a collection of callback functions. At runtime, these CPS accesses will generate the appropriate sequence of RPCs. In any case, installing the compiler is very easy. Just download it from the Clorox web site. It's packaged as a single jar file, so there's nothing else to do. It's written using Java 1.5, so you'll need a recent version of the Java Runtime to use it.
So you write code like this:
var cache = new ClientCache(new SimpleAJAXTransport("/path/to/your/script.pl"));
var cs_array = new SmartArray("basicArray", new NoPrefetchPolicy(), cache);
function printNumbers() {
for (var i = 0; i < 100; ++i) {
doWork(i);
}
}
function doWork(i) {
document.getElementById("outputDiv").innerHTML += cs_array.access(i) + " ";
}
and the compiler turns it into some ugly stuff with callbacks that does all the Ajax stuff for you. Clorox also allows you to configure whether it prefetches values or not for improved performance. You can see the framework in action in a mapping demo and a search suggestion demo.
Right now Clorox is in Alpha and has only been tested with Firefox 1.5. The documentation is brief but serviceable but more code examples are needed to provide a good framework to start your own application. Future developments will include automatic cache tuning. As this toolkit evolves, it could become the foundation for other, higher levels of abstraction. ORM for Ajax anyone?
Topics: Ajax Frameworks, Code Generation
Framework Watch - CPAINT
CPAINT (Cross-Platform Asynchronous INterface Toolkit) is a framework for remoting from Javascript. Basically it allows you to declare functions in PHP or ASP (Perl and .NET ports are underway), register them with the framework, then call them via XHR from Javascript. The framework includes Javascript and PHP/ASP utility logic to aid in producing and consuming XML messages. CPAINT also includes a proxy for calling remote web services.
CPAINT's main benefit seems to be simplicity -- it doesn't do DHTML or provide widget sets -- it just allows you call server side logic and generate and consume XML messages.
Topics: Ajax Frameworks
Saturday Roundup of New and Noteworthy Ajax Sites
Each week sees the introduction of new Ajax powered sites. Rather than announcing them one at a time, I thought I'd batch them together on the weekend.
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.youngpup.net%2F2006%2F10%2F09%2Fscreenshot.png)
MyESPN Beta - built on top of Prototype and Scriptaculous, this Beta has some nice features. Check out how the layout, image and font sizes change in response to resizing the browser window. Check out the RSSJSON and other modules. If you want to some code reading, here is a good place to start. 
Bulletin - Indian GEO:GEO (pronunciation GEE-OOH) refers to one's Geographic location. This geographic location could be one interested in or one lives in. At Bu.llet.in, GEO refers to Org, City, State and Country taken together.
What does it mean? It's sort of a news and information posting site that filters by the above criteria. Built on top of a bunch of Javascript frameworks: Prototype, YUI, etc.
Data Mashups - It's a portal. It's a mashup. (The Beta is a little pokey.) Data Mashups is an interesting concept that's a bit difficult to explain in so short a space. Think of it as infrastructure to combine data sources, business services and UI in a portal. Built on top of YUI. I was successful in getting it to lock up both Firefox 1.5.x and IE6, so maybe a little more testing is in order.Topics: Ajax Applications
IE7 Security Vulnerability Discovered
I've been on the road and had a little registry crapout (makes me feel all warm and fuzzy about the "all stick and no carrot" release of Vista), so I've been postponing the upgrade to IE7 until I've had a chance to get home and restore from backup. Right now I actually feel pretty fortunate that I've been unable to upgrade.
Is anyone surprised that a security vulnerability has been reported for IE7? This site claims that there is some sort of cross domain vulnerability in IE7. Reading the code a bit, it looks like the back end site can redirect an XHR request to a site of it's choice using a 302 HTTP redir. Why is this a security vulnerability? Imagine that you work for Goldman Sachs and you are accessing a nifty social bookmarking site villa.ino.us. This site makes an XHR request that redirects you to intranet.gs.com, or whatever the super secret internal intranet is. With a little bit of cleverness, you can adapt some of the http vulnerability scanning scripts to make use of this hole.
Scary business. This hole needs to be closed and quick.
Update: Looks like the actual attack vector is Outlook Express, not IE7. Still a problem, just a different source.
New ZK Google Maps Component
Integrating a third party mega widget like Google Maps into a server-side framework like ZK or Echo2 is not so straightforward. At best these widgets sit there on the page sending and reacting to events independent-of and invisible-to the Ajax app in which they are embedded. At worst they consume and generate conflicting events and confuse the heck out of themselves and the server-side framework's client engine.
The ZK team has taken up this challenge and has just released a ZK component that allows you to embed Google Maps in your application. With this component you can now both issue and respond to events from the server-side. For example, the following zul code allows you to use a ZK slider component to zoom a map:
<zk>
<gmaps id="map" width="500px" height="300px"/>
<slider maxpos="17" curpos="${map.zoom}" onScroll="map.setZoom(self.curpos)"/>
</zk>
Right now a limited set of events are supported, but more is on the horizon:
We have demonstrated how to use this new ZK gmaps component, the Google Maps component. The Google Maps API is a versatile API set. The ZK team will integrate more functions and events into the gmaps component so ZK application developers can control it easily.
We are going to discuss the "behind the scene" in another smalltalks about how this Google Maps API is integrated as a ZK gmaps component; especially how to route the Google Maps javascript event back to server as an ZK event. Sit tight.
Consider the possibilities: maps that zoom and pan in response to server-side events, such as election results coming in; maps that update realestate listings as a user types a query; listings that are updated based on where a users pans the map. I can hardly wait.
Topics: Ajax Frameworks, Ajax Widgets, Google, ZK
A Response from Laszlo Systems
Jim Grandy, the director of OpenLaszlo from Laszlo Systems, took the time to respond to my post from yesterday on the criticisms of OpenLaszlo from Flash/Flex developers. He also took me to task for publishing claims about failed OpenLaszlo projects:
I think you did yourself a disservice by picking an inflammatory and attention-seeking title and then posting anonymous allegations. Frankly, I could come up with any number of "failed project" anecdotes about every significant technology I have ever worked with, so it's not that impressive or useful to make a claim like this. How many times did folks fail to deploy Flex-based apps? How many Flex2-based apps have been abandoned? Why would you call in a Flash developer to rescue an OL project? Were those rescue missions successful?
I will take his criticisms to heart. No matter whether I trust my contacts, a claim that cannot be verified and critiqued by either myself or the reader is not worth publishing. Here then are Jim's comments.
Hey Dietrich,
If you'd like to talk to some *OpenLaszlo* developers, drop me a line and I'd be glad to get you in touch. Flash development is really a very different beast than OpenLaszlo development, and in my experience not too many people are fully informed with both, so you might want to collect some OpenLaszlo data points so your comments are more interpolation than extrapolation.
One factual correction:
+ OpenLaszlo's scripting language is ECMAScript Edition 3, aka JavaScript 1.5, aka JScript 5.6. It's correct that there are (minor) differences between ActionScript and OpenLaszlo's scripting language, but in my opinion ActionScript is the outlier -- you can port DHTML/Ajax code libraries to OpenLaszlo much more easily than to Flash.
And some responses:
It's arguably a good thing that OL is a version behind Flash. First of all, high market penetration of new Flash players is not immediate, and we try to have OL releases available before penetration tops 80%, which is where most Internet (not intranet/kiosk) project cycles are initiated.
And second, OpenLaszlo is compatible with Flash 6, 7, 8, and (in emulation) 9. Flex 2 is only compatible with Flash 9 native. If you want to develop in Flex against the 95% penetration player, Flash8, you have to use Flex 1; Flex 2 only works in Flash 9 native. So developers with previous investment in Flex 1 apps need costly retooling to run in Flash 9 native, whereas OpenLaszlo's cross-runtime architecture means you will be able to run the same app across multiple current *and future* runtimes as they are supported. As a datapoint, we brought our Calendar demo, a 3700 line app, into DHTML by changing fewer than 1% of the code.
In fact, the "Flash is proprietary" argument is one of the big reasons OpenLaszlo is expanding to include DHTML and JME runtimes. Would you want to deploy a multi-million dollar app against Flex 2 when Adobe's strategic interests for the Flash platform may not be in alignment with your own over the long term? With OpenLaszlo, not only are we not aligned with Adobe, we're not captive to Adobe either -- and since the project is open source, you don't have to be in alignment with us either.
Furthermore, if you've seen our Calendar demo running in DHTML in FireFox 1.5, you'll know that there's no Flash monopoly on clean, animation-rich user interfaces -- DHTML is as capable a Flash in that regard. So the "Flash advantage" may not be so much after all. (I should say we are enthusiastic about being hosted on Flash 9 native -- it appears to be significantly faster then Flash 8 or 9 in emulation mode.)
And finally, with regard to your unsubstantiated claims of "failed projects", all I'll say is that there's a word for this rhetorical technique in usenet: it's called being a "troll". I almost didn't reply to this posting because I didn't want to give you more traffic, but we're a small company and don't have the PR reach of Adobe so we have to be clear about our advantages whenever we can.
Web-o-lutions
We have seen many evolutions in website concepts and design over the years. I was talking to my colleague Matt Nolker and I noticed a book on his desk - it was the Internet Design Project book, edited by Liz Faber, published in 1998.
It showed a bunch of commercially marginal but visually impressive sites from the late nineties; back when people put a great deal of energy into brochure sites. And some of them were beautiful - let’s take Swoon as an example. Great graphics, idiosyncratic vernacular forms. Nice work, yet it just looks like a dead zone eight years later.
It made me realize that brochure sites are beyond dead. This is not an easy admission, as I have a couple languishing out in the electronic ether. The currency of websites now is their very currency. When does it get refreshed, what value can be packed up and taken away, or better yet consumed now? Immediacy is so important that aesthetics are largely irrelevant.
With the expectation of daily content, the visuals fall into two classes; an access point to an information nugget or a focussed experiment. For the everyday maintenance, static, highly mediated marketing images are pointless. Look at ten sites and email me if you find a photograph of a business person who isn’t a stockphoto. Look at 20 sites, and you will start to see the same photos recur.
What a site requires is a visual language that is extensible, and dare I say these words, fun to update.
Topics: Best Practices, Ideation, Story Telling
Internal Architecture of the Information Architect
In a recent Adaptive Path e-newsletter, Jesse James Garrett made the following appeal:
I'm trying to get one or more photos of my Elements diagram "in the wild"--that is, pinned to cubicle walls. I could stage one, I guess, but I'd much rather have the real thing. Can anybody help me out?
I first noted Garrett's interesting--and possibly revealing--association of cubicles with the untamed and uncultivated badlands--as IAs, we are capable of wreaking havoc, but generally maintain a somewhat civilized environment, as minimum standards go.
But, as a group, I do believe that we are creators and collectors of the artifacts of our craft, and indeed, I often find myself a meta-architect of my work: the taskflows, wireframes, and visual designs of each project are constructed, iteration by iteration, level by level on the foundation we refer to as "The Wall." We trace backwards through the project lifecycle in a paper-based archaeological "dig," peeling away the finished product to re-discover the initial pencil sketches and Post-it notes.
As for my own current, cubicle-bound "wild kingdom," personal real estate prevents a personal reproduction of Garrett's (patently architectural) Elements diagram, but I have used it as a visual reference in earlier days. Now, in the space I have, I've built a small thatch of project ephemera, office procedures, and an ever-changing set of Guiding Principles scribbled on scraps of paper.
Sorry, Jesse.
OpenLaszlo Considered Harmful
Yesterday was the good, tomorrow will be the good again, and in general I will have more good things to say about OpenLaszlo than bad, but today I have some bad things to say nonetheless, from my conversations with some Flash developers. I've picked an appropriately inflamatory title to go with it, but before you leave flame comments, understand the origins of the title (see below).
I picked the brains of a number of full time Flash developers of my acquaintance, so -- from my notes -- they had the following things to say about OpenLaszlo:
That last point has me a little worried. I didn't get a consistent answer as to why these projects were troubled or which version of OpenLaszlo was used. It could be they were all just Flex biggots and didn't like how OpenLaszlo worked. It could also be that the professionalism of OpenLaszlo developers was not that high back then.
Does anyone else have project experience with OpenLaszlo that they would like to share?
---
Back in March of 1968, the great Computer Scientist Edsger W. Dijkstra published his now classic essay "Go To Statement Considered Harmful." His well thought out argument, on why the Go To Statement made it hard to undestand and support programs, has made it to the top of the list of best practices in software development -- don't use gotos. His contentious title caught the interest of computer scientists and made them read it in the first place. So take the title as the tongue in cheek, discusion inspiring reference it is meant to be.
Topics: Flash
RoR and OpenLaszlo Together
I hope to have a number of things to say about OpenLaszlo this week, both good and bad. First, let me say that when I first experimented with OpenLaszlo, it struck me as nice presentation layer scaffolding for a more substantial server-side framework. I didn't expect that framework to be Ruby on Rails, however. Nonetheless, in my travels around the web I came accross ROpenLaszlo and the OpenLaszlo Rails Plugin. From the ROpenLaszlo web site:
ROpenLaszo is a Ruby interface to the OpenLaszlo compiler. It allows you to compile OpenLaszlo programs from within Ruby, in order to integrate OpenLaszlo development into Rake or Rails applications.
Combine it with the Rails Plugin:
The OpenLaszlo Rails plugin makes it easy to use OpenLaszlo client-side applications with Rails. It includes generators and scaffolding for creating OpenLaszlo applications, connecting them to Rails REST controllers, and displaying them within Rails views.
and you can generate interfaces on the fly and hook them up with a REST-based RoR backend. Throw in the fact that Laszlo will do DHTML before too long, and you can see the possibilities. Some rough edges on all of these tools, but other framework designers should take a lesson on how to integrate OpenLazlo as a presentation layer.
Topics: Flash, Ruby on Rails
GWanTed - GWT Without Programming
Writing GWT apps and widgets is not the most difficult thing in the world for developers. But what about mere mortals who want to plug a GWT powered widget into a web page and go? Well, there is hope for these poor souls in the form of GWanTed. Right now it consists of this sparse sourceforge project and the following GWT developer forum post:
GWT is great for developing new rich interface components and with it you can develop your custom widgets easily.
On the other side, in pages already made, I think that GWT integration isn't so trivial. A small step is needed. Currently, you can't use GWT widgets directly in your pages, because you need to KNOW GWT (to build an integration module). So, in a way, we're working for people that don't need to learn java for create web pages, and like with HTML objects (inputs, by example), it's easy to think about "portal widgets". Web designers don't need to know intense javascript for cross-browser compatibility, and there is where we can help... We hope! 
With GWanTed, we have different focuses. We've tried to create a base not only for creating web 2.0 apps with a bunch of out-of-box features that we think that will make easer the construction, as well as minimizing GWT's learning curve.
They promise to have more docs and explanations up shortly. In the meantime, the project page does contain some screenshots.
Topics: Ajax Frameworks, Ajax Widgets, GWT