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

Jerry Daniels jerry at daniels-mara.com
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  
browser.

Best,

Jerry Daniels

Makers of Galaxy 1.5
http://www.daniels-mara.com/new_in_galaxy_1_5.htm



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 proactive-intl.com> 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
> www.himalayanacademy.com
>
> Get Hinduism Today Digital Edition. It's Free!
> http://www.hinduismtoday.com/digital/
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the use-livecode mailing list