What will scripting do for us? Where does it fit in to our existing toolset, and with the tools we've been planning to build? Scripting needs to be considered within the overall context of end-user customization and the Application Editor. We need to have a pretty good idea how these other pieces work and what they do for us before we can get very far with the Chandler Scripting design.

We already have a scripting language in Chandler - it's called Python! Any effort we make to build an additional scripting system will need to fit between the serious level of Python programming with tools like the Application Editor, and the casual level of end-user customization built in to Chandler. We hope that Chandler will be more flexible than other PIMs, so ordinary users will naturally do a lot of customization. Chandler Scripting should be viewed as a logical extension to user customization, designed for the power user. This next step into the scripting world should also be a clear step in the direction of learning Python, or even as a bridge to Python programming. Ideally, the simplest parts of Python will be available in the scripting language, but the complicated, difficult or error prone parts will still be shielded from the script writer. To use a swimming metaphore; everyone can "splash around" with customization, the more adventuresome can safely "get their feet wet" with Chandler scripting, then really "learn to swim" with Python.

A few words about timeframe: I don't know when any of this stuff will be built. I imagine that some parts might get done in the Westwood timeframe, but it might be good to have a separate development track that's not tied to Westwood to reduce expectations, and allow more independent development. In these musings, I've basically ignored real-world practicalities like timeframe for implementation. We're certainly going to get Canoga out first.

What do we mean by end-user customization? In the cell-phone world, a few things immediately come to mind: designer face-plates and custom ring-tones. The faceplates let you express your style and individuality, while helping to make your phone instantly recognizable as yours. It's not clear how this idea would map over into the Chandler world, but the ring-tones have a clear analogy. I'd love to have custom audible alerts to let me know that mail has arrived from one of the Contacts that I consider important. E.g. a sweet "Hey Honey!" sound whenever I get mail from my wife. Or a firm "Ping" when I get a share update on the important Calendar Event I've been planning.

Clearly one of the areas users will want to customize is their Contacts. My friends Danny and Wayne would like to annotate their contacts with the information they find important. Danny plays golf, and wants to enter a golf handicap for his friends so he can better organize his annual tournament. Wayne plays bridge, and wants to add a "bridge partner" field for his friends, so he can keep track of who normally plays with whom. This kind of customization takes us straight into Schema editing to extend the Contact Kind with attributes that could be simple integers or even bidirectional references to other contacts.

I think the Application Editor, as envisioned, will handle Schema extensions like this, and probably a whole lot more. The name makes me think of a 3rd party parcel creator/editor - an idea that really excites me. When I last looked at the wiki there wasn't much information about the Application Editor, but that was 4 months ago. I feel like I already have a vision for what it can be, both from talking with John, and from years of using tools like VB and Interface Builder. I know John has had this tool in mind when building parts of CPIA and when creating the Repository Viewer. But is this tool something that the casual user will feel comfortable with, or something that only power users should attempt to use?

Someone told me recently that a study of HyperCard showed that only 3% of users actually did any scripting at all. However, most users installed the scripts created by their power-user friends. I wonder if Mitch knows similar statistics about 123? So I think most user customization for Chandler will follow those lines - people will install stuff made by others. We can probably make install/extend really easy by allowing "sharing" of installable extensions. So the question is, what kind of customization will end-users want to do beyond installing extensions built by others? Can we make schema extension simple enough for Danny and Wayne?

HyperCard had a concept of user power level that I'd like to consider adapting for Chandler. For Chandler, the bottom level people are users that just install and run works by others. The first level up allows them to edit properties and preferences. The next level up allows them to extend schema, but not modify anything they have not created (for safety reasons). The next level up provides access to Chandler Scripting and modifying existing schema. And above that the user can activate the Application Editor. All of the upper levels allow them to share their customizations with others, so bottom level users can leverage off of all of their friends who are at a higher level. I'd like to see Creative Commons licensing for these sharable works, so anyone can build off of anyone else's work freely without worrying about licensing issues.

I think the Application Editor is a whole topic unto itself, but I'm really excited about it. I think the underlying richness of Chandler will allow us to build something that's really great without too much work. I also think that the user will be able to do a LOT without needing to write any XML or Python. Ideally, Chandler Scripting will be tightly integrated into the Application Editor and generate Python code so most users won't need to write Python.

What about Chandler Scripting? I danced around the issue today, but I plan to go into depth on my vision for Chandler Scripting later this week. I've worked for many years on Scripting, and about three years ago I started thinking seriously about what I'd like to build next. I was SO HAPPY to find Chandler, because we're building most of the required subcomponents. Also, the more I learn about Chandler the more I think that my vision for scripting will fit nicely into Chandler. For instance, I've been thinking about a property sheet/spreadsheet metaphor for about two years. It has a few issues, but I'm hoping Mitch can help me out with them.

-- DonnDenman - 14 Sep 2004

There's a book by Bonnie Nardi called A Small Matter of Programming reporting on her research with spreadsheet users, where she found, as you report, that a very small percentage of people made macros but that a high percentage used macros.

That would imply that we'd like to make it really easy to share customizations, but that means that we need to pay really close attention to security issues.

• DuckySherwood - 15 Sep 2004