Re: [PW-dev] latest demonstration of widgets
Status: Alpha
Brought to you by:
spadkins
|
From: Stephen A. <ste...@of...> - 2001-10-11 13:54:43
|
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
|