Is it possible to build software without really programming? Many systems can easily build user interfaces through drag and drop manipulation, but these systems fall short when it comes to adding custom behavior to those interfaces. Some kind of programming has always been required filled this gap so users can connect their domain-specific knowledge to the interfaces to create their custom software.

With Chandler users will be able to develop fairly complex behavior without really programming. We have three concepts in mind that help make this possible:

• UI Blocks can connect with each other automatically
• Users can drop prepackaged "Behaviors" onto blocks
• Scripting will be more like editing a spreadsheet than writing a program

Each of these features allows the user to construct some behavior without taking the big jump into the programming world.

Here's how these features work: After the user has laid out their user interface components, the blocks can automatically connect to one another. This is done through event broadcasting, which allows blocks to discover and connect with each other. Chandler already uses this mechanism to allow communication between different panes of the user interface. The ability to dynamically connect allows individual panes to be moved, removed, or duplicated without needing to manually maintain connections. The automatic connections provide a flexible system.

Now the blocks are laid out, and they are interconnected, but have no real behavior. The second feature allows users to add prepackaged behavior by simply selecting a package and dropping it on a block. These "Behaviors" are not a new idea, but they can be somewhat difficult to implement in static languages. The dynamic nature of Python should allow us to extend our current "Delegate" mechanism to allow dynamic addition of delegates, which are these "Behaviors". The user can mix and match different Behaviors in their blocks to produce a wide variety of useful capabilities. Our hope is that a consistent set of useful behaviors can be delivered with Chandler, and that third parties will expand the library from there.

Two things about the Behaviors are worth noting. Behaviors can send events, so they can auto-discover blocks with related behaviors. Behaviors can have user-editable parameters, which allows the user to customize the operation of the behavior. Lets look at an example. The user chooses a behavior that plays a sound when it gets a "play" event. The user can edit the "sound" property of the behavior to pick which sound to play, or even add their own sound. Another behavior sends an event when something new is added to a collection. The user can edit this behavior's outgoing event property; changing it to "play". Now the user drops both behaviors onto their "In" box, and it will play a sound of their choice whenever new mail arrives.

Editing values in property sheets is one of the main methods of customization that will be routine for Chandler users. We leverage off of this familiarity by integrating scripting into the world of the property sheet. Where a user can enter a value for a property, we'll allow them to enter an expression, similar to entering a formula into a spreadsheet. The expression will use a simplified form of standard Python syntax, and can include references to other properties, or properties of other objects. This simple extension will go a long way to providing custom behavior.

The main advantage of using the spreadsheet style for our scripting system is the ease of use. The overall control-flow logic is no longer explicitly created by the user, instead the computer compiles a dependency tree and uses it to determine the control flow. Using this system, many common programming errors are are unlikely to be encountered. For instance, there's only one expression that determines the value for a given property, so there's no way for it to get modified by another part of the program. Undefined variables are self-evident because they show up as properties that have not had any expression defined for their value, and can be flagged graphically.

There are several additional advantages of using spreadsheet style scripting. One is that the user no longer needs to choose the order of execution. This reduces the programming burden, and provides a better possibility for parallelism. Another is that an author can easily designate some properties to be user editable, but leave the others hidden or "locked". This should make it easy for the script to be packaged as a "Behavior", inviting the end user to edit those properties needed for configuration.

To make the spreadsheet metaphor work well, we'll have to address some of their weaknesses, like the control flow constructs. The "if" statement has little power in spreadsheets, and iteration can usually only be done over sets of cells. Spreadsheets are limited by their two-dimensional presentation. I think we can overcome all of these limitations, but I don't have all of the details worked out.

One open issue is how to deal with circular references between properties. With traditional spreadsheets, a circular reference is an error, although I've heard there are systems that can iterate until values stabilize. I think that our dynamic environment demands a more dynamic approach to this problem. I'd like to investigate using a phased-value approach, where all values are computed based on the results of the previous phase of computation. This should make it very easy to build some constructs, like toggles, oscillators, etc. But it may prove confusing to users, so we'll need to do some research to see if this is the best approach.

Maybe the biggest open issue is how to deal with conditionals. I'd like to investigate using "Production Rules" to handle conditional execution, because it's had good success with other systems like StageCast Creator. Production Rules allow definition of a set of patterns, and rules to be executed when the pattern matches. For our system I envision a set of expressions that activate additional property sheets when they evaluate to true, thus activating additional program logic. Some programming languages like Erlang are using pattern matching to provide a similar effect.

Overall, I think the benefits of using spreadsheet style scripting outweigh the potential problems. It will clearly position us in a space where scripting can be done more casually and with more confidence by non-programmers, and it will integrate well into our overall design.

-- DonnDenman - 14 Sep 2004