Re: [PW-dev] latest demonstration of widgets

[Stephen A. <ste...@of...>]

Hi,

At 10:45 PM 10/10/2001 +0200, Issac Goldstand wrote:
>On the one had, I think it looks incredible.  I really love it.
>On the second hand, it looks incredibly heavy, and looks like most of the
>work is server side, requiring a full refresh from the server every time you
>click on a widget - that could get long and tiring really fast, don't you
>think?
>
>Just my $0.02...  Keep up the great work.
>
>  Issac

You provide a good opportunity for some more comments...

 1. In general, web application user interfaces stink compared to their
    client-server (or stand-alone) counterparts.  This is due to (1) a 
    lack of graphical richness, and (2) the delay incurred by a round 
    trip to the server.  The strength of web applications is that they
    are universally accessible (any browser, anywhere).  The Perl Widget
    Library is designed to (eventually) address both of these weaknesses
    while not sacrificing the strength of universal access.
 2. The demo (AppFrame.pm) is an attempt to see how close I can make the
    look and feel of a web application come to a familiar desktop
    application (i.e. Outlook). 
 3. How heavy is it? One demo page I checked was about 32K. (All of the
    images get cached, so they don't get downloaded every request.)
    This compares to 16K for a typical Yahoo! page. Not too heavy.
    In fact, if it *looks* heavy but it is not, this would be good.
    I have a 56K modem, and the app is currently a CGI program.  It
    returns to me in about 3 seconds after each click.  After it gets
    a mod_perl Controller, it should perform even better.
    Also, the dressing all around the main application "window" is the
    result of AppFrame.pm.  An application is a collection of screens,
    dressed up with an application frame to provide navigation, toolbars,
    etc.  If one desired a "lighter" look, one could write a different
    application frame widget.
 4. Server-side processing? All web programming uses server side
    processing.  Universal access requires that the application run without
    recourse to JavaScript, Java, or other client-side execution engine.
    However, once I get the "round-trip to the server on every click"
    method working, I can begin to optimize using JavaScript if available
    on the user's browser.  Good candidates for these optimizations are
    the TreeView, the SelectorView (outlook bar), and type validation on 
    data entry widgets.
 5. The current demo has the AppFrame implemented as a table instead of
    frames.  Frames are coming, but I wanted to demonstrate how far we
    could get without frames.  The application will look more polished
    when the AppFrame can use frames, and not everything gets refreshed
    every click.  Furthermore, when we use JavaScript, we can begin to 
    exploit some browser-specific features of IE4 
    (window.offscreenBuffering).  This will make the the page refreshes
    much less "tiring" to look at.
 6. The trick in all of this is to create a simple design so that all of
    the complexities of how to implement widgets are hidden within each
    widget's code. (frames or no frames? javascript or no javascript?
    offscreenBuffering or not? style sheets or not? etc.)  
    That's why I keep reworking the core plumbing.  My vision is that 
    developers can really assemble a web application from parts (each 
    potentially very complex) without having to know what goes on inside
    each part.  Furthermore, developers with skills in JavaScript or
    Java can create widgets which are easy to plug in without the (perl)
    developer having to know anything about those client-side technologies.

If I claimed that all of these things were possible, not many people would
believe me.  (I sometimes wonder myself.) ;-)  That's why I keep posting
demo URL's to show what I have been able to make work.

I'll keep you all posted.

Stephen