- 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
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
