How Else to Interact with Browser (was Re: Revolution Web Browser Plugin)

Jerry Daniels jerry at
Mon Nov 6 14:51:52 EST 2006

I like your analysis of the situation here. Helped me clarify my own  
thinking. Thank you, Swami.

I use Basecamp a lot, but I am tempted from time to time to write a  
Rev front end to it so I don't have to wait for the Basecamp engine  
to render my pages that could already be rendered in Rev Basecamp  


Jerry Daniels

Makers of Galaxy 1.5

On Nov 4, 2006, at 10:17 PM, Sivakatirswami wrote:

> Well, I'm way out of my depth here so for Dan's .06 cents I can  
> perhaps
> put in .01 cents.  mostly musings...
> I'll state my bottom line first and then launch into a long  
> dissertation:
> One way Revolution can look at the browser is the same way I look
> at Fed Ex. The browser is simply a facile window to the underlying
> "real" internet, which is just wires and sockets connecting computers.
> The browser is a delivery mechanism... take it one step further... the
> browser is to Revolution like, Time Oceanic Cable is to our  
> institution:
> A contractor which assists us in the delivery, installation and  
> configuration
> of the tools we need to begin communications.  i.e. in this model
> a) the browser has no relationship to presentation or content and
> b) assumes if user resistance to downloading a plug-in fades, then
> from my experience, that same "resistance loss" will appy equally
> to downloading a standalone player. So then, we don't need a plug-in.
> If we can get them to download anything... we can get them
> to download a standalone, or player
> OK then: the browser simple provides
> a) a window for access to services
> b) a comfortable environment for installation and configuration of  
> tools.
> c) useful "components" (as Thomas mentioned)  which we won't
> detail here: (HTML snippets, access to data on other web sites
> AltBrowser if you want it, http calls to xml files etc...)
> ~~~~~ hold you breath.. dissertation begins:
> Right within our own work group of 20 people here and within the  
> limits -- space of
> those directly interesting in our web content around the world.
> (and audience would put in the 100,000 + users bracket, not giant,  
> but also
> not small....) I see both trends at work:
> 1) on the one side we see the well-known strong resistance,
> resist using "proprietary" tools (plugins)
> The "ostinate resistance" is a protective mechanism:
> users  are overloaded, time wise, information wise, learning curve  
> wise etc...
> They have a strong desire to protect their creative-productivity time
> against the wave of "IT doodle" that threatens, in a very real  way,
> them from getting any "real work" done in a given, say, 2 hour period.
> I think it's really important we understand this in this discussion.
> It is not resistance to plug-in, player, widget per se.
> The other obvious resistance relates to security and the level of  
> intrusion
> the user feels he is exposing himself to. 10% of those subscribing to
> the Hinduism Today Digital Edition are using bogus email addresses.
> on the other hand, this same user has no  problem entering his real
> email address on a yahoo user group... he knows and feels comfortable
> with yahoo.
> What does this tell us:
> it has a lot, everything in fact, to do with brand awareness, trust.
> My own brand awareness in the internal work group may be very low.
>  If I send an email to someone here with a REv app attached, he  
> will resist the process
> of saving it to his hard-drive, installing it somewhere where he  
> can find it.
> I will get intercalm calls asking what to do.
> That same user has no resistance to going on to the web and clicking
> a button that  says "Download for Mac" ... going through familiar  
> steps...
> he doesn't ask for help.. he know it ends up on his desktop, or  
> downloads
> folder, he clicks etc....
> If we understand mind of the user here....this may help in all this  
> discussion.
> others will have other useful insights: to get "user requirements"
> and "usage studies" into this mix of ideas...and they are *not* all  
> the
> same.
> 2) On the other hand... for any given application or content that  
> has a niche
> market where end user demand is extremely high, these "obstinate"  
> users will suddenly
> do a complete about face. iTunes  is the obviously "macrocosmic"  
> example.
> If your desire to listen to some music or audio content is that  
> strong. you will
> go thru any amount of "pain" to get that thing installed on your box.
> If the iTunes network library on our main server here goes down,
> those "addicted" to music will stop their work and get up and
> do anything to get it up and running again.
> Point: there is zero resistance if demand is high enough
> and the "brand" is trusted.
> Has anyone tried to download Real Audio player lately?  Wow! talk  
> about
> making the user jump through hoops. But obviously people will and
> do continue to install Real Player on their boxes.
> If you have some YY userbase that is salivating for your ZZ  
> content, they will
> do anything to get it... At which point, one has to raise the  
> question:
> if that user base has such a high demand for your content,  does it  
> have
> a level of trust that will suffice to get them to download a  
> standalone.
> If the brand awareness is raised to a sufficient level, trust goes  
> up and download
> resistance fades to virtual zero.
> OK, this analysis  on the surface leads back to the position  
> already stated:
> we really don't need a plug-in, or as was stated, "the time for a  
> plug-in has already passed."
> i.e. the browser is just "FedEx" for Revolution.
> 3) So "interact with browser" means simply  "delivered by browser"
> and looks to vie with the coming of Adobe's Apollo which has to
> be taken very seriously. Despite the hype over AJAX, Javascript/DOM
> we  continue to see steady, serious migration to desktop internet  
> enabled apps where
> vendors' engineers are really, really sick of playing the browser  
> compatibility
> game, and in very real $ terms, see a desktop app as a viable  
> alternative for
> content and application delivery. They get the job done in 1/50th  
> of the time
> and simply tell their client base "If you  want this, download it,  
> we no longer
> deliver inside a browser...." period, end of discussion, end of pain.
> "OK so, it's not running inside Explorer, (or Safari or Firefox)
> It works better, we can provide you better tools and you
> will have fewer problems, grow up, get used to it."
>   i.e. again the browser is FedEx for apps. Spend 100 man hours  
> building
> JS for dynamic CSS for DOM that serves .10 content, versus building  
> your own
> UI painlessly, with fun, in Revolution to serve 100.00 content in  
> 1/10th the time.
> Some companies are finally waking up to how they have been duped by
> browser dominance and the real cost over time.
> I'm not saying that it would not be really great to have some powerful
> RevStack-->Browser Window options, but consider this
> It has more to do with marketing strategy.
> Let's let  Revolution provide the "iTunes" engine/standalone player,
> that will do everything except blow up your hard drive,
> unless you change prefs to allow writing to disk. In otherwords, we  
> stop
> delivering things like my Himalayan Academy Stack Player, or Key  
> Ray's Player,
> or whoever's player... Instead, we all help position a RunTimeRev  
> Player as a
> new kind of "internet app" brand... i.e. we really don't have to  
> build anything new
> at all, just educate the market and turn Runtime Revolution into a  
> "trusted
> vendor" ... so, just as anyone downloads Acrobat Reader... people   
> all over
> the  world are downloading the "Revolution Player."  one location  
> on the
> internet, well branded, making people feel secure, it appears  
> everywhere,
> it appears in Version  Tracker... in the news, on each of our  
> sites... articles
> in magazines, etc. one vendor, one app...
> Of course this "Universal standalone Runtime Revolution Player",
> to succeed, will need to have all the externals,
> including those which are now limited to enterprise users
> most importantly, dBase  drivers to open source MySQL and
> PostGreSQL... well supported by Revolution, professional installers.
> upgrade notices, etc.
> I'm afraid I also fall into the same category as Tom:
> "moved to SC and roadster but eventually gave up on the idea of a  
> web side app
> because I always expected the browser to act like a full fledged  
> application and
> it is just too limiting an environment for that. Instead, an  
> application that integrates
> web components truly is more powerful and useful for me."
> And I take Andre's and the other post on the difficulty of melding  
> Revolution with
> the browser also seriously. "Oranges and shoes"
> If we could actually build a bug-free, cross platform "Roadster"  
> style plug in.
> (highly unlikely, despite the "nothing is impossible" postion of  
> some) we would still
> have to market it... And if we can market and over come download  
> resistance to
> a plug-in, why waste the time selling people on the idea
> of what will be, in the end, a hobbled web app (which it will be,  
> no matter
> how  well you build it)   and
> a) save all the $ resources for  building such a
> plug in and
> b) plough that same money into the existing engine and
>  into a marketing "branding awareness"campaign for
> "The All New Incredibly Powerful Revolution Player!
> A Quantum Leap For the Future of Mankind.
> Internet Enabled Software for the 21st Millenium and Beyond"
> (smile... you get the idea.)
> Which of course we already have it....this has the advantage (and I  
> agree with
> Brian on this) that Rev folks $ stay focused on the engine as it is...
> and we pour our "brain power" into making this player become something
> amazing... AltBrowser would also be part of it.... RunRev Company  
> home page
> will become a "comfort zone" for users... "ahh, let me download the
> latest player, it works, I'm safe here, this is great stuff, they make
> it so easy for me..."
> then, those who are in love with Java/DOM/AJAX/Browsers, can do that
> and those who want to build and deliver full-fledged Revolution  
> applications
> can continue to do that...
> Sivakatirswami
> Dan Shafer wrote:
>> Since I've made as much noise about this over the years as anyone,  
>> I figured
>> I'd better not bypass this chance to provide what I hope is clear  
>> input on
>> the subject.
>> For me -- and this may well be overly simplistic -- there are  
>> three kinds of
>> applications: desktop apps, browser apps and client-server apps.  
>> Rev is
>> outstanding at the first, more than adequate (even excellent in  
>> some cases)
>> at the third, and not much help at all with the second. I'm  
>> talking here
>> about full-blown applications that are delivered to and run nearly
>> completely inside the Web browser environment. Examples include  
>> writely,
>> dabbleDB, JotSpot, BaseCamp, and others. The key idea -- for me,  
>> at least --
>> is that the software uses the admittedly confining presentation  
>> space of the
>> browser window as enhanced by the poorly named AJAX technology set  
>> and
>> requires the user to download nothing. Those are the kinds of apps  
>> in which
>> I am presently interested, which is why my level of activity with  
>> Rev has
>> dropped off considerably in the past few months.
>> Now, I'm not at all sure it's either necessary or appropriate for  
>> Rev to try
>> to wedge its technology base into that space which is now largely  
>> dominated
>> by JavaScript but which also includes examples of other scripting and
>> programming languages such as Ruby, Python and Smalltalk.
>> I am decidedly NOT interested in any app solution that requires my  
>> end user
>> to download a plug-in or anything else.
>> Flash is a terribly interesting DELIVERY platform for this class  
>> of apps but
>> the development tools for creating such apps suck big time. There  
>> is clearly
>> an opportunity here for a way to build an app in Rev and then  
>> compile it to
>> Flash and deliver it entirely via the browser. Similarly, there is  
>> a great
>> opportunity for doing the same thing and producing AJAX output.  
>> This is the
>> direction taken by tools like Laszlo and Flex, which essentially use
>> JavaScript and XML as their linguistic platforms.
>> That's my $0.06 (inflation taken into account along with the  
>> length of my
>> response). :-)
>> On 11/3/06, Lynn Fredricks <lfredricks at> wrote:
>>> WHAT ELSE? What other options are there? Id like to frame this  
>>> question
>>> also
>>> within the bounds of use - if you suggest something, is there a  
>>> practical
>>> use you can think of?
>>> Before diving into the Roadster model, I ask that you go back and  
>>> read
>>> discussion on the list. I have a very strong opinion about this  
>>> since I
>>> was
>>> directly involved in the last rev of the Roadster plugin for  
>>> SuperCard.
>>> Best regards,
>>> Lynn Fredricks
>>> Worldwide Business Operations
>>> Runtime Revolution, Ltd
> -- 
> Om shanti
> (In  Peace)
> Sivakatirswami
> Get Hinduism Today Digital Edition. It's Free!
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:

More information about the Use-livecode mailing list