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

Sivakatirswami katir at
Sat Nov 4 23:17:34 EST 2006

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 
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 
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 
others will have other useful insights: to get "user requirements"
and "usage studies" into this mix of ideas...and they are *not* all the

2) On the other hand... for any given application or content that has a 
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 
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 
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 
and simply tell their client base "If you  want this, download it, we no 
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 
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... 
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...


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)


Get Hinduism Today Digital Edition. It's Free!

More information about the Use-livecode mailing list