4. Client mockups and prototypes

From: John J. Deneen (jjdeneen@ricochet.net)
Date: Fri Aug 18 2000 - 15:46:24 PDT


WebWriter II Editor for Responsive Interaction for a Large Web
Application

Ref.
http://www-db.stanford.edu/~crespo/publications/meteor/PAPER86.html

Perhaps this exerpt about the WebWriter II Editor is of some help? Any
interests in the source code?

6 Future work

We plan to incorporate the Meteor Shower Architecture into the WebWriter
Page Generator. This will allow programmers to quickly develop powerful,
highly interactive web applications. For example, such a system could
allow a programmer to develop an application like WebWriter using
WebWriter itself.

We have improved the interactive speed by reducing the number of times
that the application needs to go to the server. However, for those times
when the application does have to go to the server, speed can still be a
problem. We will explore ways to improve interactive speed between the
client and the server. One way of doing this is to reduce the time for
starting up the server. This can be achieved by running a daemon that
provides the services. The CGI script could then be a very simple
program that simply opens a socket connection with the daemon and
requests it to perform the services on its behalf.

7 Summary

We have taken PARC's WebWriter Editor, an editor for HTML-based
applications, and re-designed it to get improved interactive speed,
reduced server load, and reduced screen clutter. While the old system
used only server-side CGI scripts, the new architecture uses a
combination of CGI and client-side JavaScript. The server downloads to
the browser a parsed version of the HTML page to be edited; the browser
executes JavaScript code to handle editing operations on that page. The
JavaScript code itself is structured according to the editor's new
frame-based interface, which divides the screen into areas for
previewing the
page and holding control panels. One or more JavaScript-enhanced HTML
modules correspond to each frame, and are downloaded when needed.
Updating the screen after a user action often requires only redisplaying
a sub-part of the window, such as a frame or a GIF image. The server is
only used for fetching and saving files, parsing HTML, and starting up
the system.

This architecture, which we call the Meteor Shower Application
Architecture, improves interactive performance by generating new pages
on the client, thus avoiding network and server-startup delays. The
reduced number of accesses to the server also reduce server load.
Finally, screen clutter is reduced by using JavaScript image replacement
instead of radio buttons to display the current cursor.



This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:51 PDT