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

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.

Thursday, April 3, 2008

Web 2.0 Rock Star Competition At MySQL Conference

MySQL Conference & Expo 2008 If you are planning on attending the MySQL conference in Santa Clara next week, you should definitely check out the BoF session Tuesday night 4/15 @ 8:30 Ballroom E, titled "Be a Web 2.0 Rock Star"

Anand Pandey of MySQL will be conducting a hands-on training session on the open source WaveMaker visual Ajax studio.

For added excitement, there will also be a speed Web 2.0 code-a-thon with judging by Jay Pipes and cool prizes (not to mention free beer and roving Elvis impersonators)

Release your inner geek at this festive Web 2.0 code-athon!
  • For newbies, get an up-close look at the latest Ajax and Web 2.0 technologies.
  • For rock stars, prove that you've got what it takes to be a Web 2.0 rock star!
This BoF mixes hands on tutorials for Ajax and Web 2.0 newbies with the action and excitement of a white knuckle coding competition.

Rules for the Web 2.0 Rock Star competition:
  1. Start with a blank screen and your favorite Web 2.0 tools
  2. Build a cool Web 2.0/MySQL app in 30 minutes or less
  3. There is no rule 3
Wanna Be Elvis for an Evening? Here's How
Our panel of distinguished gearheads will award prizes in 5 categories:
  1. Fastest Web 2.0 in the West - most functionality in the shortest time
  2. Coolest Web 2.0 app - most likely to appear on TechCrunch
  3. Funkiest Ajax widget - most strangely fascinating UI
  4. Gnarliest database call - unleash the beast inside of every MySQL server!
  5. Geekiest Ajax app - most Knuth-worthy implementation

Wednesday, April 2, 2008

7 Reasons Not To Use Flex

Thomas Hansen of Gaia has an entertaining anti-Flex rant here (with even more entertaining comments featuring an array of Adobe Flex stooges all commenting as Anonymous).

I'm not sure I agree with all his points (see my State of the RIA market post or Really Idiotic Approches to RIA), but sometimes it's just fun to stir the pot. Here are his top 7 reasons not to use Flex:
  1. Adobe Flex effectively don't care about any of the web standards we have spent the last 4 decades building
  2. Adobe Flex is a BINARY RIA Framework
  3. Adobe Flex will effectively render your website invisible to Search Engines
  4. You don't know the technology needed to use Adobe Flex
  5. You don't know who'll win
  6. Adobe Flex is immature technology
  7. Adobe Flex is lock-in technology

As the commenters very ably point out, however, Flex is beautiful, cross-browser and works today. Us Ajax folks have got some catchin' up to do!