Tuesday, April 29, 2008

The Case For WYSIWYG Ajax Tools

[This article is based on a talk by Scott Miles, WaveMaker architect and module owner for Dojo Grid, and Steve Orvell, WaveMaker engineer and core committer for Dojo, that they gave at the Visual Ajax User Group]

Ajax developers expect too little of their tools! Why do we put up with endless code/debug cycles with our favorite Ajax library just because there is no way to visualize a UI while you are developing it?

Imagine life without Firebug. Now estimate the amount of time you spend in Firebug just trying to figure out why a particular widget didn’t render the way you wanted it too. A WYSIWYG Ajax editor takes away a great deal of needless widget layout pain.

Just as importantly, a WYSIWYG Ajax editor provides a much easier on-ramp to learning Ajax programming, opening up a much larger market opportunity. Today, the perceived difficulty of learning Ajax can drive developers often choose proprietary solutions by default.Until it is easy to build Ajax user interfaces, the ability to build rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools.

Why Visualize Your UI?

Why do you want to visualize your UI while you are building it? As the client gets thicker, the interactions get more complex. As interactions get richer, the potential for wasting a lot of time coding grows. To torture a metaphor: in Ajax, a picture of your UI can save a thousand lines of code.

Alex Russell of Sitepen talked about saving ourselves from the unweb at the Visual Ajax User Group on the value of Semantic HTML for building Ajax apps. From our perspective, the semantic web may be coming, but it ain’t here yet (look here for more on the open web). In particular, HTML parsing and rendering can be slow. While other visual design tools may take different paths, the particular approach that WaveMaker chose was to use JSON (Javascript Object Notation) instead HTML/XML.

How a WYSYWYG Ajax editor works

A WYSYWYG Ajax editor is meant to make Ajax widget layout easy, without hamstringing the developer. The general things that any visual Ajax editor needs to be able to do include:

  1. Ajax page designer: the page designer includes palettes of widgets, a WYSIWYS page editor, and property inspectors to change widget properties.

  2. Drag and drop: developers can move widgets from the palette onto the page designer.

  3. Visual feedback loop: developers can see how their page will look and change widgets on the fly to see the effect on the design (e.g., sizing, positioning).

  4. Generate Ajax code: the Ajax editor generates the appropriate css, html and JavaScript to implement the design at runtime.

  5. Import/export widgets: there is a straightforward way to create new widgets and import them into the Ajax editor to create a robust ecosystem of 3rd party widgets.

Rules for making WYSYWYG-able Widgets

Ideally, a WYSYWYG editor should be widget agnostic – it should be able to support several different Ajax widget libraries. More importantly, people who build widgets should design the widgets up front for visual tool-ability. Good widget design can reduce or even eliminate the back-end coding needed to bring a widget into a visual Ajax tool.

WaveMaker is a visual Ajax designer that can host a variety of toolkits and widgets. Our experience developing WaveMaker has enabled us to crystallize seven widget design principles that simplify the task of hosting the widgets in a visual design tool:

  • Portability is critical: no matter how good a tool is, developers need the flexibility to switch tools. If the output of a WYSIWYG Ajax editor can’t be edited in vi, then the proprietary lock-in may outweigh the tool’s short-term benefits. Similarly, a widget that introduces its own markup language will require its own proprietary tools (think Silverlight).

  • Performance counts: an Ajax editor needs to produce Ajax apps that have acceptable load times and responsiveness, making it easy, for example, to produce minified JavaScript.

  • Well defined dependencies: make it easy for the tool to discover and incorporate images, css and other libraries required by a widget.

  • Limit create only functionality: a WYSIWYG tool need to be able to change properties like sizing and positioning dynamically, not just at the time of widget creation. Having to recreate the object every time a property changes is inefficient.

  • Straightforward APIs: widgets should follow an API naming convention (e.g., for getting and setting attributes) that simplifies exposing properties through a visual tool.

  • Automatic re-rendering: Widgets should also be responsible for updating their visual representation when their properties change. One good way to do this is via property setter methods.

  • Make it easy to expose events: a naming convention where all event methods start with onFoo makes it easier for a tool to be smart about what events a widget can respond to and then expose them in a straightforward way.

A good example of a WYSYWYG-able Widget is FCKEdit. This is a heavy-weight widget that is completely self-contained and comes with an Ajax-friendly JavaScript integration technique. On the other hand, FCKEditor does not expose resizing hooks (we had to figure that part out on our own).

Dojo Dijits contains a whole library of WYSYWYG-able Widgets. A visual Ajax tool like Wavemaker can easily wrap Dojo widgets with Javascript “meta-data” descriptors that allows the studio to create generalized property editors. The same process can be used to make other Ajax widget libraries available within studio, such as Google Gadgets and Ext.

Tooling the Dojo grid

The trick in tooling a complex widget is to determine what behaviors to tool. The goal is to provide the right subset of features through the tool without preventing the developer from going in afterwards and creating what they need.

For example, the Dojo grid is tremendously capable. Not all these capabilities are accessible through WaveMaker, such as fixed columns, combined cells and subrows. Think about all the things you can do with Excel and how long it took for Excel to get it’s grid tooling right. In the same way, WaveMaker is exposing a subset of Dojo grid features today, and will increase the richness of those capabilities over time.

Options for representing the Dojo grid data included raw javascript, table markup and json.

An equally difficult challenge is deciding what code to generate to implement a given Dojo grid definition. In general, there are three options:

  1. Semantic HTML: generate HTML that includes rich Dojo grid semantics

  2. Raw Javascript: chuck HTML and define the grid in Javascript

  3. JSON: uses an object notation instead of semantic HTML to speed parsing

The following three sections give examples of these different approaches

Semantic HTML Markup definition for a Dojo grid

The following example comes from the Dojo Nightly builds grid tests. It shows a way to use “enriched” HTML to define a Dojo Grid (a la Alex Russell). The really cool thing is that this code runs even if JavaScrip is turned off in the browser.

If you already know how to code html tables, this is an elegant approach. However, its elegance and readability is offset by the performance hit the application takes in parsing the HTML.

<table dojoType="dojox.grid.Grid"
query="{ Title: '*' }"
style="width: 800px; height: 300px;">
<th width="300px" field="Title">Title</th>
<th width="5em">Year</th>
<th colspan="2">Producer</th>

Raw Javascript definition for a Dojo grid

The following example shows setting up a Dojo grid using raw JavaScript. Although JavaScript is powerful and expressive, this essentially junks sSemantic HTML concept in favor of just getting ‘er done. is, however, confusing and difficult to read.

<script type="text/javascript">
// a grid view is a group of columns
var view1 = {
cells: [[
{name: 'Column 0'}, {name: 'Column 1', width: "150px"},
{name: 'Column 8', field: 3, colSpan: 2}

Json definition for a Dojo grid:

Json (JavaScript Object Notation) represents a third way to represent grids. To see this in action, look at the widget source tab in the WaveMaker page designer. The main benefit is that it is readable and plugs easily into a visual Ajax tool JSON provides a highly readable, name/value pair approach to defining widget parameters. Best of all, it provides a format for widgets that parses and renders quickly and enables easy data interchange between the visual studio, the browser and the application server.

dataGrid1: ["turbo.DataGrid", {}, {}, {
column: ["turbo.DataGridColumn",
{caption: "Name", columnWidth: "50px"}, {},
column1: ["turbo.DataGridColumn",
{caption: "Addr", columnWidth: "100px", index: 1}, {},


Until there are visual tools that simplify the task of building Ajax user interfaces, the ability to create rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools. WaveMaker is an example of an open source development platform that includes a WYSIWYG Ajax editor. Try it out and let us know what you think at http://www.wavemaker.com/downloads

Wednesday, April 23, 2008

Really Simple Web 2.0

Web 2.0 apps look all shiny and bright, but we all know what horrors lurk within the typical enterprise IT shop. Web 2.0 will not be able to transform the enterprise until it can deal with real world integration nightmares like CICS systems, flat files accessed through obscure SNA protocols and AS/400s programmed in RPG.

Who is going to tame all this real world IT stuff and bring it into the bright shiny Web 2.0 world? SnapLogic and WaveMaker, that's who!

WaveMaker and SnapLogic announced today a partnership to use SnapLogic's Really Simple Integration platform to wrap any legacy data source as a web service. Once SnapLogic has "tamed the beast", WaveMaker provides a point and click, WYSIWYG development platform to expose legacy systems via rich internet applications.

Although we are performing very different tasks, both SnapLogic and WaveMaker are getting incredible value from creating web service-based products. SnapLogic wraps any data source as a web service, while WaveMaker assembles applications from any collection of web services. Chris Marino of SnapLogic also blogged about our partnership.

The following marketecture diagram shows the power of this approach. Rather than a rat's nest of one-off adapters, replicated data and custom data conversions, there is one clean API to the data - web services - and one simple tool for exposing the web services - WaveMaker!
To demonstrate the power of the rich and thin approach to web 2.0, WaveMaker and SnapLogic will be demonstrating an application at Web 2.0 Expo this week that integrates mainframe, minicomputer and relational data into a simple inventory tracking and re-ordering sytem. Stop by our booths and check it out!

Tuesday, April 22, 2008

Why WaveMaker Went Mac (& Why We Ain't Going Back)

A year ago, I bought a Dell desktop running Windows Vista. Last week, I finally got it working…mostly.*

This week, we are releasing WaveMaker for the Mac (OS 10.5 Leopard to be specific) and Safari. Although the Mac is a visual platform, it has always been behind on WYSIWYG development tools. With Wavemaker, the Mac is leaping back in front.

The WaveMaker Visual Ajax Studio download for the mac is at http://www.wavemaker.com/downloads or just click here.

After many years of languishing in the education and design ghettos, Mac has once again become the defacto standard of leading edge techies. I attended an open source CEO conference recently where I was the only PC user at a breakout session of 10 people.

Our press release included a spiffy quote from Jean-Louis Gassé, General Partner at Allegis Capital and ex-Apple executive: "WaveMaker's Visual Ajax Studio for Mac comes at a very opportune time. Apple is gaining momentum in the Enterprise and WaveMaker gives enterprise users an easy and visual way to build Web applications."

Mac developers had their moment, back there in the days of Hypercard and Filemaker pro. Now the Mac platform is becoming a defacto standard for developers once again.

Here are some of the key reasons the entire silicon valley seems to be moving to the Mac:
  1. Ajax platform of choice: Safari is lightning fast and leads the pack in standards-compliance. I can't remember the last time I saw any web app demoed on Internet Explorer, and if Firebug* ever gets ported to Safari, Firefox will be in trouble.
  2. Video platform of choice: we just went through a 3 week death-march to create a new screencast for WaveMaker. Of that time, about 8 hours was spent creating content - the rest of the time was spent wrestling with the brain-dead video software we were using on the PC (Camtasia). In contrast, my 12 year old niece just created a 30 minute class presentation using i-movie. Enough said.
  3. The Incredible shrinking desktop: with more and more compelling web applications, I find myself spending less and less time working within my Windows desktop.
  4. The disaster that is Vista: given that I have to relearn the whole user interface to move from XP to Vista, I might as well relearn an interface that actually makes sense.
  5. That cool backlit logo on the Mac laptop: let's face it - the knowledge that you will look good in a coffee shop probably sells more laptops these days than Ghz or RAM stats.
When I was in college I saw Steve Jobs demo the Apple Lisa in front of about 30 of us Stanford Comp Sci nerds. It is still to this day the best demo I have ever seen, despite the fact that the Lisa flamed out famously. I know that Macs will never take over the world, but it's sure nice to see them back in the race.

Then there's also the part about it just plain works! Which brings us back full circle to my Dell/Vista saga: after spending dozens of hours, many hundreds of dollars on utilities that didn't work, and a spectacular lack of help from Dell (the answer ended up being on an Intel site, having to do with the Intel Matrix storage manager, not that you really wanted to know).

Interested readers may also want to check out another good blog post on why PC developers are moving to the Mac.

*corrected - original post confusingly said Firefox, causing a great deal of what passes for glee among the trolls ;-)

Monday, April 14, 2008

Visual Ajax Webinar Thursday, April 17 at 12 PST

The next Visual Ajax User Group webinar and meeting will be next Thursday, April 17 at 12 PST. The speakers will be Scott Miles and Steve Orvell. Scott is the module owner for the Dojo Grid and Steve is a core contributor for the Dojo Grid. They will be talking about "Ajax Grids - Taming and Tooling The Widget Beast."

To attend the webinar, send an email to rsvp@visualajax.org

Our last meeting was a lively discussion led by Alex Russell on how to overcome the structural challenges of Ajax entitled, Saving Ourselves from the Unweb.

If you wish to attend in person, the meeting will be at the offices of WaveMaker Software, 301 Howard Street, 22nd Floor

Our next two meeting will feature Ajax experts from two ends of the mashup spectrum:

Please let us know if there is a topic or speaker you would like to see in an upcoming meeting by sending email to info@visualajax.org. For more information on the Visual Ajax User Group, click here.