Actual vs. Possible (was 'Menu woes')

[Richard Gaskin]

Ben Rubinstein wrote:
> - I believe I have come to an uneasy peace with the behaviour - but still
> sometimes get caught; but I have to be careful not to disturb the peace, and
> I don't think that Richard's suggestion that we should embrace the fear and
> treat it as a learning experience addresses this.

My suggestion was not to embrace fear but rather the opposite, to ignore 
it entirely -- I'd written:

    When faced with the option to chose between experimenting
    on a backup to see what happens or not doing so out of fear,
    experimentation will yield more useful results.

Aside from that small misunderstanding, I loved all of the specific 
suggestions in your post, esp. that they accomodated backward 
compatibility for currently shipping aps, and strongly recommend that 
the folks at RunRev give it a second read:
<http://lists.runrev.com/pipermail/use-revolution/2004-December/048850.html>

That said, I'd like to take a moment to explore something that seems to 
drive some of discussion on this list:


When it comes to menus, documentation, and a number of other issues, 
there's often a split among the contributors here, with some explaining 
how what's being requested can be done and others explaining how that's 
not good enough.

I think both are right, and that it may be useful to consider the 
differences between the two.

When I come across a question on this list, I try to find a solution 
using whatever means we have currently available.  My assumption is that 
the poster is working on something that they need to get out the door, 
so I tend to focus here on the merely pragmatic rather than the ideal.

But beyond how to ship apps today, there is also an interest in 
exploring possible ways to ship apps ever more easily in the future. 
That's very valuable, of course, but also I think it's useful to 
remember that it's a very different thing.

When someone with Chipp's experience posts a question here, he's been 
around the block enough times to know how to sort through posts to get 
to what he's looking for.  In this latest case he got same-day service 
to lead him the two lines he needed, and now he can ship yet another 
cool app in his large and ever-growing collection of Rev-based products.

But I'm more concerned here for new users: it may be too easy for them 
to walk away from this list feeling that the whole thing's too broken to 
use, and will remain so until some unknowable date in the future in 
which RunRev might possibly implement all of the suggestions posted here.

The Improve-Rev list was established as a venue for focusing all that 
positive energy toward finding ways to make app-building ever more 
convenient.  The XTalk list is another venue for exploring ways to 
enhance the core language, as is the RevDocs list for refining ideas 
about improving the docs into specific recommendations.

As these explorations of enhancements become more refined, ultimately 
the best place for them is Bugzilla, where everyone can review and vote 
on them.  This is especially true for bugs:  complaints here may provide 
healthy venting, but posting them in Bugzilla is the most productive 
step to seeing them resolved.

I'm no ListMom and it's certainly not up to me to interpret the charter 
of this Use-Revolution list (I have my hands full managing my own 
product forums).  And like I said, I agree that exploring possibilities 
for ever-greater convenience are very valuable.

All I'm asking for is to see what we can do to move these things from 
the category of "possible" to "actual", and near as I can tell the 
existing venues are the most effective means of translating good ideas 
into results.

This carries an additional benefit for the core audience of this Use-Rev 
list:  it increases the percentage of material here that's focused on 
using Revolution to get results now.

Sure, Rev's as imperfect as anything in else in our imperfect world. And 
sure, it can be made better, and better still.

But in the meantime, there's nothing stopping any earnest soul from 
creating killer apps in Rev right this minute.  Apps built with Rev as 
it is (and even how it used to be, more limited in earlier versions) 
have won glowing reviews, made a strong ROI for their publishers, and 
made hundreds of thousands of end-users around the world very happy.

No one on this list started out as a Transcript expert. Once upon a time 
the only expert was the man who invented the engine, Scott Raney, and 
even he had a few things to learn along the way.  Most of the folks on 
this list have managed to reach at least competency with nothing more 
than what we have today. Many have become quite expert (my favorite 
example this week is Christopher Condit's wonderful Dynamic Digital 
Maps, which he generously makes freely available at 
<http://ddm.geo.umass.edu/>).

Programming doesn't seem all that different from tennis, math, or 
playing piano in this regard:  the folks who do it well spend lots of 
time practicing, are comfortable learning from mistakes, and seek the 
advice of others who've already made a lot of mistakes.  As Phil Davis 
(the man who taught me most of what I know about working with custom 
properties) reminds me:

   Good judgement comes from experience.
   Experience comes from bad judgement.

:)

So while we make good use of the means available to improve the product, 
let's not lose sight of the person who posts a question.  Chances are 
they're working on something right now, and chances are they can have a 
solution right now.

My wish for 2005 is that the number of Rev-based apps in circulation 
will double, which translates to a lot of happy developers and a far 
greater number of happy end-users.  If we point these developers to what 
they need, they can ship today.

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