Actual vs. Possible (was 'Menu woes')
ambassador at fourthworld.com
Mon Jan 3 03:47:58 EST 2005
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:
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
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
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.
Fourth World Media Corporation
Rev tools and more: http://www.fourthworld.com/rev
More information about the Use-livecode