x: novice#1

y: novice#4

z: novice#2

real problems for branching scripts!!

arrows

grey/dashed for multiple branches?

could show different scripts in different colors

CreateVirtualMouse {or CreateMagnifier}

MoveTo[FindViewer[ScriptedDocsDesignNotes.tioga].Save]

Wait[.5 sec]

MouseButtonDown[yellow]

Wait[.1 sec]

MouseButtonUp[all]

has a variety of audio capabilities

can specify a sequence of actions/commands => toward XDE ToolDriver

a. Intermedia: a small dot represents a link, apparently a separate dot for each link.

b. If we want annotations to be playable outside a script (which may not make sense -- a previous scripted location may need to have set some variable or opened a file or something), then each one must be separately visible. Certainly if there were such a annotation/button capability, then scripts could make use of them. If annotations aren't playable outside scripts, then Suresh's suggestion to make only the script starting location visible has merit.

c. One of Stephen's goals was to make voice annotations noninvasive to a document's layout. Thus you can't have more than one on a given character. They can also only be placed on a single character. (When a selection is longer than a single character, TiogaVoice will place the annotation on the last character.) A generalized annotation capability would allow multiple annotations per character, with tags on the annotations so that they can be filtered. (Could easily be added to TiogaVoice through char props.)

a. Certainly action annotations, or annotations in general,

a. Intermedia: select loc1/start link/select loc2/stop link paradigm. A user issues the Follow command to go from one location to another.

b. Current design: each entry has a sequence number. The user edits the sequence number field (and other fields, such as action & timing) in the script tool as desired, selects the desired location, and then clicks AddEntry. The entry is added to the script after that sequence number. This and the above show only the current entry (but can do FindEntry on prev or next to discover info about them).

c. Have scripting actions automatically build up a textual script in an associated viewer. To map from the document to the associated script entries, want script entries to be visible (at least during script writing).

a. Intermedia: a map of a hypermedia document is a thumbnail sketch of each portion (they tend to be small), with the links between the portions shown (apparently not to specific places in each portion).

b. Connectivity:

c. Document context:

d. Document locality & sequentiality:

e. All, but not very visual: textual representation, with ways to map from script to document & vice versa.

For all of the following, store list of <scriptUID, entryUID> on doc chars as $script property.

a. Storing (relevant) script linking info in doc:

b. Storing script in (LoganBerry) db:

Generalized annotation mechanism

Generalized scripting mechanism

Generalized grouping mechanism

User interface research

To handle branching, with multiple annotations/entries at a single doc loc, have an operation that takes a doc loc and opens a window for each annotation/entry that refers to that loc (in the given script only? If not, then how to find public and private scripts? AHA! use LoganBerry public/private merging capability! User will have a private script db specified in user profile and system will have a public one, just as telephone directories.). Then the writer can point to the desired window and say branch to that entry. Need a way to copy script entries from one script to another -- could use the preceding mechanism, by allowing the windows to be editable, so the user can edit in the changed script name (system provides script uid?).

allows lookup from fname to find all scripts, lookup from scriptUID to prefetch files if desired.

if scriptUID & filename are keyed attributes, can look up all entries w/ same filename and then prune those to find all different scripts that touch that file. Similarly to look up all entries w/ same scriptUID, then prune to find all files that script crosses. BUT the multiplicities will slow things down over a single <scriptUID, filename> pair.

to find first entry of script, peel off scriptUID and look for scriptUID#start entry in db.

to find first entry of script, look up entryUID in db to find scriptUID

then look up scriptUID#start entry in db.

unfortunately, this probably won't quite work, because the user could add a new entry to the beginning of the script. At that point, could give this (old) entry a new UID, and have the new one become scriptUID#start. Would require possibly complex updates if other entries point to (in their next or prev field) that entry. (But prev field doesn't work for nonsequential scripts anyway.) If sequencing info is part of each entry, then a next field that points to the first entry in a script represents an infinite loop (for infinite demos?)

A. Keep an internal representation until the document is saved, then write to the db.

B. Write to the db as soon as a script or entry is created.

Discussion: A makes less sense when scripts can cross document boundaries (which was one of the reasons for storing them separately from the underlying document, in a db), because scripts now have essentially separate lives. However, B does not have the semantics that we have become accustomed to, where one creates/edits a temporary file, whiteboard, or whatever, and saves it explicitly when desired. This temporary behavior allows experimenting with changes without committing oneself to them. (On the other hand, some systems already have permanent behavior: for example, changes to one's Walnut db while reading mail are permanent updates.) So....

C. Keep an internal representation until the user issues an explicit SaveScript command, then write to the db.

D. Write to the db as soon as a script or entry is created, but allow undo to a previously-marked spot.

More discussion: C is the obvious right choice, although it does require a new command for the user (who may be glad of the separation anyway). D does not work because a single user may be working on multiple scripts simultaneously, or multiple users may be updating the same db.

E. Use a Cypress db instead. Write to the db as soon as a script or entry is created, but only commit the transaction when the user issues an explicit SaveScript command.

Still more discussion: E accomplishes the same effect as C without the effort of an internal representation, but requires the extra effort and unknown constraints of interfacing to Cypress rather than LoganBerry.

If a script entry is deleted by removing its character(s), the thread of the script is irretrievably lost, and there is no way to go on to the next entry (the next field is gone). This might be a particular problem when a document is edited outside the scripting system's knowledge.

Never mind: this is not true now that scripts have a separate Save operation. Instead, the script entries will remain, but will point to file versions/character positions that no longer match. This is a much safer situation, because that entry could just be skipped (albeit with possibly odd results) or the user could be asked to help position the entry.

Actually, it wasn't true before either: the entry in the document text is only positioning information. The scripting information was to be stored in the root of the document and would be undamaged unless the user explicitly deleted it. In some ways this is preferable, because Tioga could more easily have been changed to update the script info in the root on each edit. But perhaps a more general thing could be added to Tioga: a character-independent marking capability (that would live in the root or something, Tioga would update on edits, and clients would use as desired. TiogaVoice could use the same mechanism). Maybe Tioga has this already?? TiogaOps.PutTextKey/GetTextKey => NodeAddrs.PutTextAddr/GetTextAddr is almost what I want, but seems to be limited to a single editing session. Dan says it doesn't quite work right anyway. He thinks you want something more general still: a way to register routines to be called whenever certain events happen to certain properties (which is more specialized than registering a procedure to capture all edits of a given type throughout the machine -- and the current implementation of that is at too-high a level anyway: not at the TEdit level).

1. User creates a script, with unique scriptid.

2. User creates a script entry, with unique entryid.

3. Some combination of scriptid & entryid are stored in the document to allow for future edits of the document.

4. Repeat 2 & 3 as needed to complete script.

5. Store script (and entries) in db.

6. To play back script, we

One possibility would be to write entry stubs in the db on scriptid and entryid creation, to reserve the desired ids. Those routines would return a guaranteed unique id. These stubs would cause as much as twice the db traffic as a strictly local, then global scheme.

Another alternative would be to rewrite all locids in the documents if saving a script identifies a non-unique id.

Yet another possibility would be to work harder to make the ids unique in the first place.

The general annotation layer would define locations, actions, user indicators (talks bubbles, blinking, ...) -- both for showing the existence of an annotation to the user in the first place and for indicating the playback location, and routines for inserting and deleting locations for a variety of document types. Each document type might want to implement some way of handling edits to annotated locations.

The script layer would then order these annotations into possibly complex collections.

AnnotationDB: eid, action, class, (file, chars)=location

ScriptDB: sid, startingfile, firsteid, internal//eid, sid??, nextEntries=list of (cond,eid)

If eid sequencing entries contain sid, then the same annotation can appear in different scripts. But controlling the sequencing when an annotation appears multiply in one script is a bit more difficult: the only way to avoid infinite loops in the above scheme is to manage your own counter in the annotation's action field and test it in the next field. Of course, this would mean that the annotation would have the same name, description, etc in the different scripts. If the user wanted to change that, he could create slightly-modified entries (now we want inheritance of entries??).

Another way to encode the sequencing would be to write a single sequence like this:

How about just like a program, where you are specifying the sequence of execution of the annotations:

A single annotation could always be modelled as a singleton script, and in fact one could avoid writing the script header if desired, or could provide a WriteAnnotationOnly function.

ScriptEntriesDB: eid, sid, nextEntries=list of (cond,eid), action, class, (file, chars)=location

ScriptDB: sid, startingFile, firsteid, internal

A class structure could be used to make it easier to specify annotations. It would also save space if it was done as a pointer to the procedure record, in which you made a new procedure record only if no identical one existed.

1. you may get a script that cannot be flattened into a structured "program" with sequentiality, loops and branches.

2. pointing to an annotation (even within the context of a single script) is not sufficient to specify a place in the script, because the annotation could appear multiply in the script.

eid; eid; if a then eid else eid; while b do eid; eid; eid;...

pro:

con:

could perhaps do script procedures by calling the script system to play a script as the last part of the action of the preceding entry. eg, action: open window; Script.Play[sid] next: wherever

1. You can use the location of the annotation if you wish to map one or more actions over them, such as SetBreak, edit macros, etc. Sort of like a special key for searching for EditTool DoForAllFiles activities. A bit wierd (but possibly a feature) that different types of items might be annotated. SetBreak of a Gargoyle picture,...

2. You can use the actions on the annotations to perform activities or communicate voice.

3. You can use the sequencing for pedagogy, additional communication, etc.

4. You can use the keywords to filter the annotations.

If you put up a Script button in the header, and have conventions about what script entries look like, then the user can push the button to internalize scripts in a document that looks like it has them. Seems kludgy.