Learning Revolution

[Richard Gaskin]

Mark Wieder wrote:
> Absolutely spot on. Example: in topics, searching for "static" (as in
> "static text") brings up a handful of entries, at least one of which
> talks about label fields. However, filtering on "static" brings up a
> total of nothing. Nada. Zilch.

This must be "static text" week, as the subject has come up frequently 
in multiple venues. I believe there may be two cognitive issues at play, 
both of which may be addressible in the docs and UI:


1. Implied object types
    --------------------
This issue could be seen as arising from a mismatch between an object 
model inferrable from the Rev IDE UI and the far simpler one in the 
underlying language itself.

Given the myriad icons in the IDE's tool pallete, and reinforced through 
descriptions which suggest a different native object type like "label 
field", it's understandable that one might infer that this is somehow a 
different object from an ordinary field, and indeed in many (most?) 
other languages static text is implemented as a different class from 
editable text fields.

The actual Transcript object model is much simpler:

   Text is displayed in fields.
   The lockText property governs whether that text can be edited.

I respect the apparent design initiative of the IDE's toolbar, which 
allows you to create buttons and fields with a great many properties 
preset for greater convenience.

But maybe the core question here for learning is:  Could design 
enhancements be made which would provide the same level of convenience 
enjoyed currently but also make more it more clear that most of the 
"object types" are actually variants of a much simpler set of objects 
merely with varying property settings?


2. Accomodation of common nomenclature
    -----------------------------------
"Static text" is a widely-used term in a great many languages and tools. 
  Although there is no need for a separate object type to provide that 
since Transcript's fields do it well today, it would be tremendously 
helpful to have such terms indexed in the docs so that they point to the 
corresponding Transcript term/object.

Such indexing is difficult, as it requires a significant time 
committment from the subset of available resources who understand 
multiple tools/language intimately enough to anticipate such conceptual 
overlap.

So maybe an interim process to start work on such index expansion might 
be an extension of the "user notes" facility, which would allow ad hoc 
additions to the search endex.  As related terms become evident, anyone 
could log them into a pool which is queued for the next release.

It may also be useful to see a reinstatement of the old Getting Started 
info, which included specialized orientations for new users coming from 
experience with a variety of other tools.  If that were extended with a 
reference of common terms and methods from other popular languages 
pointing to their Transcript counterparts it could play a strong role in 
flattening the learning curve for those picking up Transcript as a 
second language.

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev