Computer
`
`Networks
`
`and
`
`ISDN Systems
`
`29 (1997)
`
`1507-1517
`
`Responsive interaction for a large Web application: the meteor shower
`architecture in the WebWriter II Editor
`Arturo Crespo a.*, Bay-Wei Chang b~l, Eric A. Bier b.’
`and Science Department,
`Stanford
`University,
`Gates Bldg. Ofice
`420, Stanford,
`CA 94305, USA
`bXerox Palo Alto Research Centel;
`3333 Coyote Hill Road, Palo Alto, CA 94304, USA
`
`‘Computer
`
`Abstract
`
`Traditional server-based web applications allow access to server-hosted resources, but often exhibit poor responsiveness
`due to server load and network delays. Client-side web applications, on the other hand, provide excellent interactivity at tbe
`expense of limited access to server resources. The WebWriter
`Il Editor, a direct manipulation HTML editor that runs in a
`web browser, uses both server-side and client-side processing in order to achieve the advantages of both. In particular, this
`editor downloads the document data structure to the browser and performs all operations locally. The user interface is based
`on HTML frames and includes individual frames for previewing the document and displaying general and specific control
`panels. All editing is done by JavaScript code residing in roughly twenty HTML pages that are downloaded into these
`frames as needed. Such a client - server architecture, based on frames, client-side data structures, and multiple JavaScript-
`enhanced HTML pages appears promising for a wide variety of applications. This paper describes this architecture, the
`Meteor Shower Application Architecture, and its use in the WebWriter II Editor. 0 1997 Published
`by Elsevier
`Science B.V.
`Application generators; Www; Meteor shower; Responsive interaction; Large Web application; WebWriter
`Keywords:
`architecture; Browser-based editor; Server-based WW?V applications construction; Web page generating programs;
`Direct-manipulating Web page editor; Server-based authoring tools
`
`1. Introduction
`
`1.1. The WebWriter application builder
`
`The WebWriter system
`the construc-
`[3] supports
`tion of simple
`interactive web applications without
`the need to learn HTML or CGI programming. Mod-
`eled after HyperCard
`[ 11, WebWriter allows
`the user
`to build an application as a stack of pages, where
`each page can contain
`text,
`images, buttons, and
`other
`form elements, as well as content computed
`
`crespo@cs.stanford.edu
`author. E-mail:
`* Corresponding
`’ E-mail:
`(bchang,bier}
`@parc.xerox.com
`
`on the fly by executing scripts. The user constructs
`the layout of each page of an application using the
`WebWriter II Editor, an interactive editor that runs in
`any browser
`that supports
`frames and the JavaScript
`language [8].
`the
`The user adds application behavior using
`WebWriter
`II Editor by writing
`scripts
`that will
`be run either on the server or in the browser. Users
`without programming
`experience can add behavior
`by selecting a built-in program and filling
`in details
`for that program. For example,
`the user can select
`the built-in
`file listing program and fill in a form
`to
`specify how to determine which
`files to list.
`In addition
`to the Editor,
`the WebWriter
`
`system
`
`0 1997 Published
`0169-7552/97/$17.00
`PII SO169-7552(97)00064-O
`
`by Elsevier
`
`Science B.V. All
`
`rights
`
`reserved.
`
`Facebook's Exhibit No. 1029
`Page 1
`
`

`

`1508
`
`A. Crespo
`
`et al. /Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`the WebWriter Page Generator, a server-
`includes
`based CGI service
`that creates new pages as a
`WebWriter-built
`application
`runs. Because they use
`the Page Generator, applications produced by Web-
`Writer run as CGI programs on a web server and
`hence can be used from many platforms and in many
`web browsers.
`
`1.2. Increasing
`
`interactive pe$ormance
`
`The original WebWriter Editor was a CGI pro-
`gram so that every interaction with the user had to go
`to the server for processing. The interactive speed of
`the program was poor due to network delays, startup
`time of the server-side script, and whole screen re-
`draws at the client after each interaction.
`In addition,
`this solution was not scalable: as the number of users
`of the editor
`increases, the server becomes a bot-
`tleneck. This paper describes the architecture of a
`new version of the editor (the WebWriter
`II Editor)
`that overcomes these limitations.
`In this architecture,
`which we call the Meteor Shower Application Archi-
`tecture, both the web browser and the web server
`collaborate
`in
`the execution of the WebWriter
`II
`Editor. Operations
`that need high
`interactive speed
`are performed
`in the web browser using JavaScript,
`while
`the server executes only
`the operations
`that
`need server resources or that otherwise cannot be
`performed by JavaScript in the browser.
`The rest of the paper is organized as follows. First,
`we review related work. Then,
`to give context
`to
`the architecture discussion, we present the user in-
`terface of the WebWriter
`II Editor. We then describe
`what happens behind the scenes during a typical ses-
`sion with the editor, from starting the editor, to load-
`ing and modifying a web page, to finally saving the
`page. Having described the way the WebWriter
`II Ed-
`itor works, we generalize
`these ideas and introduce
`the Meteor Shower Application Architecture. Finally,
`we discuss the advantages and disadvantages of the
`model and give our conclusions and plans for future
`work.
`
`2. Related work
`
`There are many systems that divide an interactive
`application between a web server and a web browser.
`
`[5,2]. In
`One way to do this is to use a Java applet
`this case, very general programs written in the Java
`language are downloaded
`to a browser where they
`can interact at high speed with the user. We chose
`JavaScript over Java in the WebWriter
`II Editor
`for
`several reasons, including:
`(1) Browsers can already display formatted HTML.
`We did not want to duplicate
`this function-
`ality
`in Java. In
`the first place,
`it would be
`more work. In the second place, by using the
`browser’s formatting we take advantage of any
`improvements
`in that formatting without having
`to update our code. Finally,
`for users who want
`to preview
`their HTML
`page in a particular
`browser, our implementation
`allows them to do
`this just by running WebWriter
`in the browser
`in question.
`that building our control panel
`(2) We anticipated
`components as fragments of HTML
`would
`be less work than building
`them as calls on
`the
`java _ awt
`toolkit
`(Java’s Abstract Win-
`dow Toolkit)
`[6] or the subArctic user interface
`toolkit
`[4].
`(3) Java applets must specify a fixed rectangle as
`their size. We wanted to allow the user to resize
`the WebWriter editing
`region just by resizing
`the browser. This is easily done using frames.
`(4) By using JavaScript, we avoid the need to com-
`pile our code as we change it, so we can try out
`new versions of WebWriter very quickly.
`Our architecture
`is similar
`in some respects to
`that used by the Krakatoa Chronicle
`[7]. Like
`the
`WebWriter
`II Editor,
`the Krakatoa Chronicle down-
`loads a document
`(in this case a set of newspaper
`articles) to the browser which is then formatted at the
`browser for reading. Unlike
`the Krakatoa Chronicle,
`our system uses the native formatting capabilities of
`the browser, is implemented
`as a set of JavaScript-
`containing HTML pages, that are loaded into frames
`on demand.
`[9], a mul-
`is Netscape’s PowerStart
`Also similar
`tiple page, multiple
`frame JavaScript application
`for creating a home page. The constructed page,
`based on a small set of templates,
`is saved as a set
`of preferences in a browser cookie, and is recre-
`ated from
`that cookie on subsequent visits. Unlike
`PowerStart,
`the WebWriter
`II Editor provides di-
`rect manipulation
`editing, can create general web
`
`Facebook's Exhibit No. 1029
`Page 2
`
`

`

`A. Crespo
`
`et al./Computer
`
`Nehvorks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`1509
`
`forms and behavior, and uses
`pages that can include
`the server for file operations and large processing
`tasks.
`Other ways to provide interactive applications ac-
`cessible from
`the web include helper applications
`and plug-ins, using,
`for example Mosaic CCI,
`the
`Netscape plug-in API, or Microsoft Active X. As
`with Java applets, we rejected these methods because
`we wanted to take advantage of the HTML
`format-
`ting capabilities of the browser itself.
`In addition,
`plug-ins and helper applications must,
`in general,
`be written
`for a particular platform or browser; we
`wanted a system that would work on many browsers
`and platforms.
`
`3. The WebWriter
`
`II Editor user interface
`
`the architecture, we briefly
`Before describing
`present the main user interface elements of the new
`WebWriter
`II Editor. Fig. 1 shows a typical screen.
`The editor consists of
`five
`frames
`tiling
`the
`browser window (see Fig. 2). The
`top level page
`is invisible
`to the user; it contains the frameset (the
`HTML description of the sizes and positions of the
`five frames inside
`the browser window), the global
`JavaScript
`functions and data structures of the edi-
`
`tor. The title frame holds the WebWriter
`logo. The
`frame contains the page that is being edited.
`preview
`frame provides
`file and stack
`The general controls
`operations and cut/copy/paste editing. The object in-
`contains controls for inserting
`sertion controlsframe
`HTML elements. We refer to an HTML element
`in
`the preview frame as an “object”. The objecr proper-
`ties frame contains commands that are specific to the
`currently selected object.
`II Editor displays
`In editing mode, the WebWriter
`the current page as interpreted HTML
`together with
`images, called handles, as shown in Fig. 3.
`additional
`Handles are used to select an object; red handles in-
`dicate the currently selected object, and the blinking
`black bar next to the red handle is the insertion point.
`Selecting an object causes that object’s properties to
`appear in the object properties frame, where they can
`be examined and changed. To insert an object,
`the
`user selects it in the insertion control frame and fills
`in its properties.
`in the
`facilities available
`There are many more
`WebWriter
`II Editor, including
`those for copying and
`pasting HTML, managing multiple page applications
`(“stacks”), and specifying behavior to execute when
`buttons are pressed on the page. For a detailed
`description of the original WebWriter Editor
`from
`the user’s point of view, see [3].
`
`Fig.
`
`I. The WebWriter
`
`II Editor
`
`Facebook's Exhibit No. 1029
`Page 3
`
`

`

`1510
`
`A. Crespo
`
`et al. /Computer
`
`Networks
`
`ana’ ISDN Systems 29 (1997)
`
`1507-1517
`
`Top Level Page
`
`Title
`General Contml
`Object
`controls
`
`Preview
`
`Insertion
`
`0 bject Properties
`
`Fig. 2. WebWriter
`
`II Editor
`
`frames.
`
`*
`e The WebWriter Editora
`a*
`b What am bedoneh WebWxiterM
`**
`shapes)
`red
`and
`(grey
`Fig. 3. Handles
`(vertical
`black bar to the right of the word
`
`the
`and
`‘Editor”).
`
`insertion
`
`point
`
`4. The WebWriter
`
`II Editor architecture
`
`in order
`The WebWriter Editor was re-designed
`to improve
`its interactive performance and to reduce
`screen clutter. As mentioned earlier,
`the original
`WebWriter Editor was implemented as a CGI script,
`in which every handle selection and button press was
`handled by the server. The user then had to wait
`for network
`travel, CGI startup, and complete
`re-
`layout and redrawing of the browser window. Since
`the WebWriter Editor was designed as an interac-
`tive, direct manipulation
`application, nearly every
`click of the mouse incurred
`this delay. Exacerbat-
`ing the situation
`is the use by WebWriter Editor of
`many control elements surrounding
`the actual page
`elements being previewed - handles and insertion
`points approximately
`tripled
`the number of non-text
`
`in layout and display. Even when
`elements involved
`WebWriter was running on a local web server on
`a very fast machine,
`the delay caused by a simple
`interface operation
`(selecting a handle,
`for exam-
`ple) was still several seconds long. Although
`sev-
`eral seconds is acceptable for operations
`that users
`expect to require some computation,
`this is much
`slower than the near-instantaneous response for in-
`terface-level operations in typical non-web graphical
`applications.
`II Editor more usable, we
`To make the WebWriter
`focused on improving
`response time for interface op-
`erations, as well as improving
`the interface itself. We
`accomplished
`this in three parts: dividing process-
`ing, as appropriate, between a CGI script running
`on the web server and JavaScript functions running
`on the client browser; segmenting
`the interface into
`individually
`reloadable pages using multiple
`frames;
`and replacing
`images
`in place
`to reflect changes
`in state. The result is an editor
`in which response
`times for many operations are nearly instantaneous,
`and are comparable
`to those of standalone, non-web
`applications.
`
`4.1. Selectively dividing processing between server
`and client
`like JavaScript en-
`languages
`Browser scripting
`able dynamic behavior without the overhead of traf-
`
`Facebook's Exhibit No. 1029
`Page 4
`
`

`

`A. Crespo
`
`et al./Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`1511
`
`II Editor
`fit over the network. The new WebWriter
`was designed to use JavaScript to provide fast inter-
`active behavior, resorting
`to the overhead of a CGI
`call only when server resources are needed, or when
`JavaScript cannot reasonably provide
`the behavior
`required. For example, computationally
`intensive op-
`erations may be technically
`feasible in JavaScript but
`run very slowly. In that case, the overhead of a CGI
`call (including network traffic and page redisplay)
`is
`worth the savings in processing time.
`II
`Of the 23 modules composing
`the WebWriter
`Editor,
`four of the modules are CGI scripts written
`in the Python programming
`language
`[lo] and run
`in the server. The remaining 19 modules are HTML
`pages enhanced with JavaScript. Only
`five of the
`HTML modules are active at once, one in each of the
`WebWriter
`frames.
`The CGI modules provide server-side services
`such as loading
`files, parsing HTML,
`saving files,
`and setting up the environment
`for the HTML mod-
`ules at start up. The JavaScript modules handle
`displaying
`the edited page in
`the preview
`frame,
`selecting
`the current object, editing and insertion
`of HTML
`objects, and copying and pasting of ob-
`jects.
`In the following sections, we will show how pro-
`cessing is directed
`to the server and to the client
`as these basic tasks are performed: starting the Web-
`Writer II Editor, loading and saving an HTML pages,
`and displaying and modifying
`the page.
`
`4.1.1. Startup: using the server to create the HTML
`environment
`II Editor by in-
`The user starts the WebWriter
`voking a CGI script at the server. The server-side
`CGI script creates an HTML page with three com-
`ponents: global JavaScript
`functions, calls to build
`the JavaScript global data structures, and the def-
`inition of the frameset, as shown in Fig. 4. The
`global
`functions provide an interface
`to the global
`data structures, and provide common
`functionality
`needed by all modules. The global data includes the
`document tree, which holds the elements of the page
`that the user is editing, and global status informa-
`tion such as the position of the insertion point. The
`frameset defines the position and properties of the
`frames, as well as the URLs of their
`initial
`con-
`tents.
`
`Fig. 4. The server
`and the component
`
`functions,
`downloads
`frames
`to the browser.
`
`global
`
`data structures,
`
`Server
`
`Browser
`
`him1
`
`Fig. 5. The server
`
`startup meteor
`
`shower.
`
`When the browser receives the HTML page gen-
`erated by the server, it interprets
`the page by run-
`ning the JavaScript function definitions, creating the
`JavaScript document
`tree and storing it at the top-
`level browser window. Then,
`it creates the frames
`and requests from
`the server the content of each
`frame, starting a “meteor shower” of HTML pages
`from the server to the browser, as shown in Fig. 5.
`The HTML page sent to a frame could be static
`HTML
`(such as the one used in the title
`frame)
`or an HTML
`page that includes JavaScript code.
`Pages with JavaScript code can collaborate with
`one another via global data structures and functions
`placed
`in
`the top
`level page of the browser. For
`example,
`the HTML
`page loaded
`in the preview
`frame contains a script that translates the document
`tree stored at the top window level into an HTML
`representation with handles.
`
`Facebook's Exhibit No. 1029
`Page 5
`
`

`

`1512
`
`A. Crespo et al. /Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`Fig. 6. The general
`
`controls
`
`frame
`
`4.1.2. Loading and saving pages: using the server
`accessjles
`frame (Fig. 6) usually con-
`The general controls
`for operations such
`tains a module, general.
`html,
`files or cutting and past-
`as loading and saving
`ing objects. This module defines routines
`to per-
`
`to
`
`these commands and then describes the but-
`form
`tons in HTML. Each button contains a small piece
`of JavaScript
`that calls
`the associated
`function.
`For example, general.
`includes
`these two
`html,
`pieces, in JavaScript and HTML
`sections, respec-
`tively:
`
`function
`. . .
`<input
`
`Load0
`
`I
`
`. . . 1
`
`type=pe="button"
`
`value="Load"
`
`onClick="return
`
`Load0
`
`;">
`
`When the user clicks on a button, the JavaScript
`code associated with it is executed. The code can
`either execute locally, or it can ask the server to
`perform some service. For example,
`the “Hide Han-
`dles” button executes locally;
`first, a global variable
`is modified
`to change the display mode and then
`the preview frame is redisplayed
`to reflect the new
`mode.
`The “Load” button is an example of an operation
`that requires the help of the server. We need to ac-
`cess the server for this operation because files are
`located in a server accessible file system. When the
`user clicks the “Load” button,
`the browser pops up
`
`a dialog box asking the user to supply the URL of
`a file to load. The information entered by the user is
`sent to a CGI script that runs on the web server.
`The server tries to read and parse the URL spec-
`ified by the user. If this succeeds, the server sends
`a new frameset as in the startup process; but this
`time,
`instead of sending an empty document
`tree, it
`sends a representation of the document
`tree for the
`requested document.
`In fact, because the server is a
`Python program and the client is running JavaScript,
`the server encodes the document as a set of nested
`JavaScript calls to be interpreted by the client. These
`calls look like this:
`
`tr :ee =
`new CreateChild(new
`new CreateState('hl',
`'<hl>',
`'</hl>',
`new CreateChild(new
`new CreateState('text',
`'One Header',
`null,
`'text'
`
`)I,
`)I,
`\\ h 1 t\
`
`CreateObject(
`'hl'),
`
`CreateObject(
`",
`'text',
`
`null,
`
`'One Header',
`
`'italics',
`
`0,
`
`'bold',
`
`0,
`
`. . .
`
`)
`
`));
`where each CreateObject call adds a new object to
`the tree, and each object, in turn, may have children.
`The fragment above builds the tree for the document
`Thereaderneednotun-
`“<hl>One
`Headerc/hl>".
`
`derstand this code in detail, but can simply note its
`nested form.
`to loading a page. The user
`Saving a page is similar
`clicks in the Save button, which causes a JavaScript
`
`Facebook's Exhibit No. 1029
`Page 6
`
`

`

`A. Crespo
`
`et al.
`
`/Computer
`
`Networks
`
`and
`
`ISDN
`
`Systems
`
`29
`
`II 997)
`
`1507-1517
`
`1513
`
`to execute. The script asks the user for the
`routine
`URL
`in which the file will be saved. Then, the doc-
`ument tree is transformed
`into standard HTML and,
`with the URL,
`is sent to the server. The server does
`two operations when saving a file. First, it translates
`the URL
`into a filename, and then it stores the HTML
`as a file at that location.
`
`the HTML page: using the client
`4.1.3. Displaying
`to construct modified pages
`As described
`in the previous section, the docu-
`ment tree is a JavaScript data structure built when
`a page is loaded
`into
`the editor and stored in the
`root window. The preview frame generally contains
`
`html, which has three parts:
`module preview.
`(1) Definitions of JavaScript functions
`to walk the
`document
`tree and translate it into HTML
`that
`includes editing handles around each object.
`Using a tree data structure
`to represent
`the
`document
`improves program speed, because
`traversing this structure is faster than processing
`a linear string of characters in HTML
`format.
`(2) Definitions
`of JavaScript
`functions
`that are
`called when the user clicks on a handle.
`(3) A call
`to the JavaScript
`functions of part 1,
`which actually causes the new HTML
`to be
`written into the preview frame.
`So for example, preview. html includes:
`
`userdoc,
`function DocumentToHTML(framedoc,
`function OnClick
`(nodeID, objectPropURL)
`. . .
`DocumentToHTML(document, parent.userDocument,
`
`{
`
`showHandles)
`. . . 1
`
`{
`
`. . . )
`
`parent.showHandles)
`
`and the generated HTML
`
`includes handles such as:
`
`<a . . . onClick=ck="OnClick(264,
`<img src="left\-handle.gif">
`</a>
`
`'text.html');">
`
`the object being
`identifies
`where the number “264”
`is the name of the module
`selected, and “text.html”
`to load into the object properties
`frame in order to
`edit the newly selected object.
`to the document,
`After
`the user makes an edit
`the screen is redisplayed by calling
`the JavaScript
`) method on the preview frame. This up-
`reload(
`dates the display without requiring any significant
`interaction with the server (because preview. html
`is cached at the browser and the document
`tree is
`converted to HTML as the browser interprets pre-
`view.html).
`
`4.1.4.. Selecting an object and modifying its proper-
`ties: using the client for interactive response
`The first step for modifying an object is selecting
`it; to do this, we click on the handle that surrounds
`the object. This click
`triggers a JavaScript
`function
`that highlights
`the handles in red and updates global
`data structures to reflect the new current selection.
`The JavaScript code also loads into the object prop-
`erties frame the appropriate HTML
`file for the class
`
`of the selected object.
`The selection of an object is a small-scale meteor
`shower. Fig. 7 shows how the process is initiated
`in the preview frame, requesting
`the server to send
`the appropriate HTML
`file to the object properties
`frame.
`The final step of modifying an object is changing
`its properties. This is done through an interface that
`is object-specific. Similar objects can share the same
`interface, but the programmer can develop special-
`ized interface
`for some objects. For example,
`the
`text object has a specialized interface that allows the
`user to insert text and at the same time change the
`appearance of the text (see Fig. 8).
`The text object interface is a form that is initial-
`ized with the current properties of a text object. The
`user can modify
`those properties and then click
`the
`Done button. This triggers a client-side update of the
`document
`tree, generation of the new document view
`by reloading
`the preview frame, and replacement of
`the contents of the object properties
`frame with a
`blank page.
`
`Facebook's Exhibit No. 1029
`Page 7
`
`

`

`1.514
`
`A. Crespo
`
`et al. /Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`Server
`
`(-$,
`
`Br awser
`
`Fig. 7. Editing
`
`an object.
`
`DoneJ
`
`~Italics nBold aKeyboard -fCode,
`Fig. 8. Text object
`interface
`
`4.2. Segmenting the inteeace
`
`frames that make up the WebWriter
`The multiple
`II Editor
`interface serve several purposes. Most im-
`portantly,
`frames separate the interface
`into areas
`that can be updated independently. One part of the
`interface can change by reloading
`its page with-
`out requiring other parts to be reloaded as well.
`For example, clicking on a handle to get its object
`properties causes a new page to be loaded in the ob-
`ject properties frame, but requires none of the other
`frames to reload. Reloading
`the minimum necessary
`is an important
`factor in reducing
`response times
`during user interaction.
`the editor
`in making
`Frames also play a role
`more usable
`in realms other than responsiveness.
`Since reloading a frame usually causes it to become
`blank before the new page is displayed,
`the frames
`
`which do not change provide continuity of context.
`The editor behaves more
`like a standard desktop
`application which has selective control over what
`changes in
`the interface.
`In addition, placing
`the
`preview area in its own frame allows very long pages
`to be edited conveniently. Since the frames scroll
`independently,
`the preview
`frame can be scrolled
`without affecting
`the layout of the other controls in
`the interface.
`point of view,
`Finally,
`from an implementation
`the program.
`segmenting
`the interface modularizes
`Each possible “state” of a frame
`is a JavaScript-
`enhanced HTML
`file. As illustrated
`in previous sec-
`tions, active modules (those that are currently
`loaded
`in the frames) communicate with one another via
`global data, and cause other modules
`to be loaded
`and unloaded
`into the interface.
`
`4.3. Replacing
`
`images in place
`
`the position
`Making a new selection or changing
`of the insertion point are extremely common opera-
`tions when editing a document, and thus should be
`performed as fast as possible.
`Handles
`in the preview frame are grey if uns-
`elected, and red if selected. Clicking on a handle
`simultaneously
`selects it and deselects the old selec-
`tion. In the original WebWriter Editor,
`this required
`a server round-trip
`to redraw the page appropriately.
`In the JavaScript-enhanced WebWriter
`II Editor, this
`could be handled by the client recreating
`the page.
`However, we made use of an even faster technology
`that exists in the current Netscape browser: replac-
`ing
`images of the same size in place, without a
`reload. This allows the highlighting
`to occur with no
`perceivable time lag.
`the insertion point
`The technique
`for displaying
`also benefited
`from
`this
`technology. The original
`WebWriter Editor placed a radio button at every valid
`insertion point within
`the previewed page. Radio
`buttons are controlled by the browser, so selecting
`one is essentially an instantaneous operation
`that
`does not require a trip to the server. However, making
`all possible
`insertion points visible as radio buttons
`clutters the display considerably. Additionally,
`it was
`sometimes confusing
`to have radio buttons serving
`as insertion points mixed
`in with bona fide uses of
`radio buttons in the web page being constructed.
`
`Facebook's Exhibit No. 1029
`Page 8
`
`

`

`A. Crespo
`
`et al. /Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`1515
`
`this scheme was replaced
`clutter,
`To minimize
`with one in which possible insertion points are no
`longer explicit.
`Instead,
`the selected element deter-
`mines the insertion point. Now when the user clicks
`on a handle,
`that handle and its companion handle
`are replaced by red handles; in addition, one of those
`handles has a small bar next to it indicating
`the po-
`sition of the cursor. To make the cursor more visible
`and also more like a traditional
`text editing cursor,
`we used animated GIFs to make it blink
`(one of the
`only tasteful uses we’ve seen of blinking on a web
`page).
`
`5. The meteor shower application
`
`architecture
`
`-
`II Editor
`The architecture of the WebWriter
`multiple
`frames collaborating with one another via a
`browser scripting
`language and with the web server
`via CGI scripts -
`can produce web applications
`that “in spirit”
`remain server-based, yet are highly
`responsive. This model we call the Meteor Shower
`Application Architecture, after the meteor shower
`of pages that the initial CGI script places into
`the
`browser’s frames.
`in the
`relies
`The Meteor Shower Architectures
`functionality
`of the client browser and the server.
`The client browser provides processing
`for all in-
`terface operations,
`thereby ensuring short interactive
`response times. Since a Meteor Shower application
`is segmented
`into many
`frames, collaboration
`oc-
`curs among
`the frames as user operations
`in one
`frame cause other frames to update. Having many
`frames also limits updates to only those parts of the
`interface that require updating, potentially a signif-
`icant savings because reload times can be relatively
`lengthy compared
`to the timeframe of individual
`in-
`teractions. Furthermore,
`the client can use in-place
`replacement of images
`to indicate state changes,
`wholly bypassing
`the need to reload or regenerate
`pages.
`The server has three functions. First, it sets up
`the state of the client. Second, it provides the client
`with
`the programs
`it needs to run. And,
`third,
`it
`provides additional
`functionality
`(via CGI scripts) to
`the clients
`for operations
`that are either
`inefficient
`or impossible
`to do at the client side. This includes
`access to server resources as well as computations
`
`languages.
`for relatively slow scripting
`inappropriate
`The distribution of work in the Meteor Shower
`Architecture has the following potential advantages
`and disadvantages.
`
`5.1. Advantages
`
`l
`
`Improved performance. Because the code dealing
`with user interaction
`is in the client, we don’t
`incur any network delay communicating with the
`server. Additionally,
`because each client handles
`most operations
`locally,
`the contention
`for the
`server is not as severe as in the case of the pure
`CGI approach.
`0 Economics. There are two economic perspectives
`involved. First, by using the server for only the
`operations
`that are inefficient or impossible
`to
`perform on the client, we reduce
`the cost of
`maintaining
`the server. Second, by reducing
`the
`amount of communication
`between the browser
`and the server, we reduce the cost of communicat-
`ing through the network.
`l Scalability. The Meteor Shower Architecture
`makes supporting a large number of clients eas-
`ier than a traditional CGI approach. Again
`this
`is related to the available resources of the server
`and the bandwidth of the connection between the
`server and the browser.
`l Faster development. The Meteor Shower ap-
`proach can allow
`for
`faster development
`than
`writing applets since
`it can make use of the
`browser’s built-in
`capabilities, primarily
`the ca-
`pability
`to display HTML.
`In
`the case of the
`WebWriter
`II Editor, not only does the browser
`handle layout of all control areas, it also handles
`layout of the preview of the HTML page being
`edited.
`l Debugging. Because only a small number of mod-
`ules are running at the same time, and there is
`a very clear interface between them,
`finding a
`faulty module
`is easy. Additionally,
`the use of an
`interpreted
`language allowed us to test the modi-
`fications faster than with a compiled
`language.
`l Security. A well defined CGI interface the server
`and the browser, allows a secure environment
`to
`be maintained at the server side. Similarly
`the
`security safeguards
`in
`the browser maintain a
`secure client environment.
`
`Facebook's Exhibit No. 1029
`Page 9
`
`

`

`1516
`
`A. Crespo
`
`et al. /Computer
`
`Networks
`
`and
`
`ISDN Systems 29 (1997)
`
`1507-1517
`
`l Caching. Because browsers cache pages, both
`the appearance of user interface components
`(as
`HTML)
`and
`their behavior
`(as JavaScript)
`is
`cached, reducing still
`further
`the demands on
`server and network load. The client expect to in-
`cur a network delay for loading
`the HTML pages
`only the first time
`they are accessed; afterwards
`the pages should come from the cache.
`
`5.2. Disadvantages
`
`These advantages trade-off with problems arising
`from
`the distributed and interpreted nature of the
`Meteor Shower Architecture.
`Intellectual property. All of the JavaScript code
`l
`is shipped to the client, potentially giving away a
`significant portion of the source code. A competi-
`tor may copy this code and do reverse engineering
`to write the missing server-side code.
`is
`l Complexity. The Meteor Shower Architecture
`inherently more complex
`than the CGI model as
`it includes the challenge of a distributed architec-
`ture.
`the
`l Dependence on caching. As noted above,
`HTML modules of this architecture are cached.
`This can obstruct software development
`if the
`client holds on to a stale version of a module
`the
`developer is trying
`to modify and test. We work
`around th