[Design] Scripting and Customization (was: view/filters: default option)

[Arnulv Rudland]

> >I also believe that people won't configure things themselves, but will
> >happily use someone else's customization, as I discuss in
> >
http://lists.osafoundation.org/pipermail/design/2002-November/000676.html
>
> Agree here also.
>
> With regard to the specific proposal below, which I've snipped...
>
> At a minimum it should be possible to use a set of pre-defined views that
> work exactly the way you've laid out (or work that with some
> variations).  There are interesting questions about:
>
> what is presented as a default to the user
> how easy it is to understand and begin to learn a pre-configured scheme
and
> what we can do in Chandler to facilitate it
> how to let people make incremental customizations of a scheme if they like
> it and want to get more out of it
>
> This is all to be worked out.

In the following, I have put down some of my first ideas about a possible
design of the customization in Chandler.
I am still posting this to the Design list, as it is a

I think the clue will be to make the entry into Chandler application
customization as easy as possible without making it too dumb, so that the
"department guru" can easily get into the scripting facilities without
having to buy some "Python for dummies" book to get started.

Chandler should initially include a rich number of preconfigurated filters
and scripts which take care of many standard tasks (e.g.: "request for
mailing list manager" thread
http://lists.osafoundation.org/pipermail/design/2002-November/000690.html)

To me a three layer design seems feasible:

Layer 1: "opt-in/out".
Predefined Opt-in / opt-out rules, filters and macros dependant of the
current context. It could be feasible to include
some simple usage of parameters as a transition to:

Layer 2: "Guided scripting".
Simplified rule/action-definitions in a stripped down scripting environment
with point-and-click wizards guiding the user through the development of
simple scripts. In this environment the user can start with the alteration
of copies of the predefined customizations.
Rich access to the event hooks with the possibility to create atomic and
therefore logically simple yet effective functionality.

By choosing not to use the script-wizard, the user will eventually end up
with the:

Layer 3: "Advanced Scripting"
Full access to the scripting engine.


It is IMO important that the user can move between the different layers
without having to rethink his way of working. A negative example in this
matter is the rules wizard in Outlook - it takes you almost there, but to
improve your filter you have to start from scratch from a completely
different angle with VBA or even more obscure plug-in mechanisms to get the
job done.

Therefore the guided and advanced layer functionality should be accessible
and to some degree inspectable in the opt-in/out layer, whereas the
opt-in/out and guided scripting layer functionality should be extensible and
alterable in the advanced scripting layer.

This has some obvious implications in addition to what is already pinned
down earlier on the list:

- all customizable functionality must be implemented in the Chandler
  scripting language

- Every customization item would need some standardized meta data --
  At least for the control of:

    * End user Documentation: Name, how to use the script, etc.
    * Context applicability: can this filter
    * Argument Validity
    * Wizard-control data: which parameters of which type with which values
      (Checkboxes, drop-down lists, etc.)

- A standard wizard-framework and wizard-API is needed

- A wizard-validator is necessary to make promote level 3 scripts accessible
in level 2.



With Python set as the application programming language, there are IMO very
good reasons for selecting Python as the scripting language as well (see
also
http://lists.osafoundation.org/pipermail/design/2002-November/000623.html)

The wizard Framework and API could eventually be implemented as a plug-in.

The Windows system tweaking utility X-Setup by X-Teq (www.xteq.com) with
it's SDK is an example for a good start in the direction of guided
scripting, even if the Level 2 analogue is very rudimentary.

Best regards,

Arnulv Rudland