A Collaboration on Shafer's Books?

Gordon Webster gwalias-rev at yahoo.com
Mon Jan 24 16:20:10 EST 2005


With regard to making the time-consuming work of
producing rev/Transcript programming books financially
viable, how about something like this ...

A 2-tiered rev wiki would be set up, one tier of which
would be open access (gratis) for all registered rev
users - the other would be available by yearly
subscription and compiled/mediated by Dan (and any
other gurus he might need to help him). Here's how it
could work ...

Any registered rev user could contribute an article to
the open wiki. This could be as short as a Q&A about
how to place an icon in a button with accompanying
code snippets, or as long as an in-depth article about
the rev mesage path, XML parsing, the use of sockets
etc. etc. Any other registered rev user could read
these articles and even edit them to correct errors or
ambiguities, or just comment on them and/or polish
them up. Naturally this open wiki would be mediated by
some of the rev community in the same way that other
wikis are, to prevent vandalism or abuse. 

All submissions to the open wiki would be subject to
an agreement on the part of the authors that the
submitted material would be posted on the open wiki as
a resource for everyone to read and edit as required,
in return for the right on the part of the wiki
administrators to incorporate the material in whatever
form they see fit, into commercial publications.

The second tier of the wiki would be more book-like,
with articles and code examples organized into
comprehensive "chapters" that cover particular areas
of rev development. These would have been verified and
edited by Dan (and his team) and would/could combine
the raw materials from the "open wiki" with more
conceptual material and background into the subject,
with illustrative figures and tested code examples.
This part of the wiki would be accessible by
subscription only and although it would not be
editable by anybody other than Dan's team of gurus, it
could still be in a wiki format to enable Dan and his
team to collaborate on the compiling and editing work,
or to solict the subscriber's comments on the work.

Some limited time access to the "revBbook wiki" could
be also be included for purchasers of Rev products to
get them going with rev and Transcript. After this
initial period (say 3 - 6 months), they would also
have to pay a subscription. As a new user to rev, I
would love to have been able to have access to
something like this. Like the chapters in Dan's book,
the revBook wiki would offer a conceptual view of rev
and Transcript to show a new user the landscape and
get him/her started with good rev/Transcript
programming practices. This could also address the
common rev newbie gripe about the lack of structured
documentation - perhaps making rev more popular in the
process, leading to more subscribers to the revBook
wiki, making rev more populkar, leading to ...

More sophisticated rev users tackling some new project
would find articles that introduce them to advanced
programming concepts like cryptography, internet
authentication, the use of externals etc.

The "value" in the revBook wiki would be the access to
the organised and authoritative pedagogical "chapters"
of the kind that Dan has in his books - perhaps with
the option to print them as pdfs. The open access wiki
would still be a useful resource, but more like the
kind of searchable FAQ stuff that rev users already
have access to - but greatly expanded. 

The hook for getting people to continue subscribing
would be the ongoing updates and expansion of the
revBook wiki. Unlike a book, it could be updated
regularly and could more more closely reflect and
respond to the rev community's current
issues/obsessions/neuroses. Subscribers to the revBook
wiki could even contribute to its evolution e.g. by
voting on the chapters that they would most like to
see.

To improve the fiscal rewards for Dan (and his team),
runrev could perhaps offer yearly Revolution upgrades
bundled with yearly subscriptions to the revBook wiki.

Best

Gordon



More information about the use-livecode mailing list