SimpleNarratedDocumentsDesign.tioga
Polle Zellweger (PTZ) August 20, 1986 6:38:48 pm PDT
A very simple design for narrated documents.
To create a script, the user creates a document with voice annotations. The user then orders (some of) these annotations into a script. A document can contain multiple scripts, which can progress in any order throughout the document. In fact, I would like to allow a single script to progress through multiple documents. Scripts are manipulated via:
a) a separate tool (better for creation)
b) header buttons (better for playback)
Unresolved issues:
Are script entries visible/distinguishable from plain voice annotations?
Script creation:
Tool has a script # field also.
Add selected annotation to script (default is at end of script).
To add an annotation in the middle of a script:
a) The user selects the desired annotation
and then shift-selects the preceding entry and bugs Add(After)
or shift-selects the following entry and bugs Add(Before)
However, the user probably wants feedback about the entry number of the new entry.
b) The tool maintains a SequenceNumber field, which is where new annotations will be placed.
The user selects the preceding entry and bugs GetSequenceNumber
and then selects the desired annotation and bugs Add(After) or Add(Before)
Delete selected annotation from script. This operation does not delete the voice annotation itself. Again, the user probably wants feedback about the entry number of the deleted entry.
To move an annotation in the script, the user must delete the annotation from the script at the old position and add the annotation to the script at the new position. An accelerator for this operation may be provided later.
The tool may allow a large selection and AddAllInOrder/DeleteAll.
Script playback:
Play button: PlayNext vs. Start/Stop/Pause/Continue
Where to start playing? At start vs. at SequenceNumber vs. at selected position in document?
Start at selected position in document has the problem that there might be multiple scripts that include that annotation.
Debugging:
Show all entries of script #
display Script#|entry# as char looks of entry. This discourages the user from editing those fields (which would not be reflected back into new script positions). However, it also encourages them to search for the displayed text (which doesn't work). This is a problem for knowing whether the document has been edited (for viewer header). I was thinking of tracking fewer edit ops than Stephen did.
Show all script #s that this annotation is a member of.
Find next entry (don't play it). Find entry# n. (could use left/middle convention as Walnut to allow stepping through script easily in this way; similarly for PlayNext button)
Text editing in scripted documents:
Moving annotated text from one location in a document to another does not alter its position in any scripts it may be a member of. User feedback that this is happening?
Copying annotated text in a document will result in multiple copies of the same script entry. This will be detected as an error:
a) when the operation occurs (harder to implement)
b) when the document is saved
The user must delete excess entries or specify their positions in the script.
Deleting annotated text automatically deletes any affected script entries from the script. UNDOing a delete should reinsert the affected entries.
Implementation:
in document:
each script entry has the following fields stored as character properties:
voiceScriptID = Script#|entry# ID
*MemberOf = list of ScriptID
or voiceScript1 = ID, voiceScript2 = ID hard to search for all voiceScript properties
or voiceScriptID = List of Script#|entry#
----------
*nextID = Script#|entry# Stored here makes PlayScriptFromSelectedSpot easier, but means that system must track Tioga deletes.
Must manage voiceScriptIDs: delete voiceScriptID when last script reference goes away
or search for appropriate script when adding or deleting.
in root (when document saved) | in ScriptTool (during script editing)
List [[ScriptID1, [ID1, ID2, ..., IDn]], [ScriptID2, [ID1, ID2, ..., IDn]]]
----------
*when saved, these may have associated document positions so searching is not needed
To get the sequence number of an entry, you start at the beginning of its/all scripts looking for its ID. If this is a rope with fixed size fields, you could do some division scheme to get the sequence number. Sounds awfully complicated, and you need to separate the scripts under this scheme.