DETAILED DESCRIPTION
Referring to FIG. 1, in a prior art process for creating and displaying a web site, the user either directly writes HTML and Script Code providing user input at 1 or operates a related prior art product at 2, which generates the HTML and Script Code at 3. A separate file, with its attendant HTML and Script Code is uploaded for each separate web page in the web site at 4, which is then interpreted by a browser when accessed at 5.
FIG. 2 shows a process for creating and displaying a web site in accordance with one aspect of the invention in which, a user operates a build tool at 6, working directly with one or more of the final web pages in a full WYSIWYG mode. The build tool accepts the user input and creates a multi-dimensional embedded multimedia object database at 7. A run time generation process is then invoked to create the necessary run time files at 8 (including HTML shell, CAB/JAR files and a customized runtime engine) which are then loaded to a user\'s web site at 9. The web page(s), when viewed by a web surfer, are activated by the browser calling the customized run time engine at 10. The run time engine then begins to read the database and down load image, audio and video files, while simultaneously drawing the first web page for viewing or user interaction at 11.
Build Tool and Process
FIG. 3a shows a build tool 350 at the detailed component level. The build tool includes a build engine 352, interface 354, screen sensing mechanism 356, multi-dimensional array structured database 358, interface\'s database 360, web page scaling engine 364, time line engine 366 and installation Program 368. The operation and use of each of these components is described in greater detail below.
FIG. 3b is a flow of the build process executed by the build tool to create a web page/web site. Referring to FIGS. 3a and 3b, the process begins with an initialization (12) and continues through to a point where a web site has been defined and stored in the build engine\'s internal database (29).
The build tool 350 includes plural individual tools that are created and initialized at (12). The processes for creating and initializing build tools are described in greater detail below in association with FIG. 5. After the build tools are created and initialized at 12, the build tool 350 interacts with the user, receiving user commands (actions), for example, to build a web site. The build tool 350 processes user responses and communicates the same and status information to both the build engine 352 and interface 354 at 13. The processes for interacting with the user are described in greater detail below in association with FIG. 6.
In one implementation, the interface includes a panel (and its objects, including a menu bar, menus and sub-menus, tool bars, status fields, interactive fields and interactive pull down lists), pop-up windows (called dialog boxes in MS Windows), color and alert message interface technologies, built with HTML, Dynamic HTML (DHTML), JavaScript, and Cascading Style Sheets (CSS). Interface 354 responds to the user input and may display a pop-up window, update the interface objects, or display alert messages, as shown at 15. The operation of the interface 354 is described in greater detail below in association with FIG. 7a, FIG. 7b and FIG. 7c.
As the build engine 352 receives data and status information, it updates an internal database (part of multi-dimensional array structured database 358) and sets feature flags at 14. The processes for updating the internal database and setting flags are described in greater detail below in association with FIG. 8. To enable effective two-way communication between the interface and the build engine, polling technology is included as shown at 16. The details of the polling process are described in greater detail below in association with FIG. 9.
Whenever user input is received, the build tool 350 analyzes the input including error checking at 17. In one implementation, the input is analyzed and then processed by object type (class). The process for analyzing input to determine type is described in greater detail below in association with FIG. 10. In one implementation, the number of different object processing technology classes are four, and include direct text entry (18), image processing (19), video or audio files and links (21) and frames, tables, forms and draw objects (22). The build tool 350 processes the user input based on class. The processes invoked for direct text entry are described in greater detail below in association with FIG. 11. The processes invoked for image processing is described in greater detail below in association with FIG. 12. The processes invoked by the text button, paragraph, and image style technologies are described in greater detail below in association with FIG. 13. The processes invoked for processing audio and video files and channels are described in greater detail below in association with FIG. 14. The processes invoked for processing frames, tables, forms and draw objects are described in greater detail below in association with FIG. 15. When an image, text button or paragraph object is to be inserted in the web page, the current style that is selected in the panel defines the initial settings used when creating the object in the web page. As such, button, image and paragraph style setting and technology will be invoked at 20 depending on the user input. The processes invoked by the paragraph style setting and technology is described in greater detail below in association with FIG. 13.
After the input is processed as described above, a check is made to determine if one or more animation or transformation (interaction) techniques are to be invoked at 23. The run time engine provided in accordance with the teachings of the present invention support various user interactions, including support for numerous animation and transformation techniques, and both web page and object time lines. Depending on the user selections, one or more technologies may be invoked. In the implementation shown, the build tool 350 is configured to check to determine if the input data is related to plural technologies including: user interaction technology (24), animation technology (25), transformation technology (26), object time line technology (27) and web page transition animation technology (28). The processes invoked for user interaction technology are described in greater detail below in association with FIG. 16. The processes invoked for animation technologies are described in greater detail below in association with FIG. 17. The processes invoked for transformation technologies are described in greater detail below in association with FIG. 18. The processes invoked for object timeline technologies are described in greater detail below in association with FIG. 19. The processes invoked for web page transition animation technologies are described in greater detail below in association with FIG. 20.
After the build tool 350 has processed the user input, one or more file operations can be invoked at 29a. In one implementation, the file operations are save, save as, new, close, open, apply and web site. If open or web site are selected, the build tool 350 initiates the dynamic web page resizing process at 29c (See FIG. 22). If save or save as are selected, the build tool 350 initiates a run generation process (See FIG. 4 and FIG. 24). File operations close, open, and new can also initiate the run generation process, based on the state of the build process and user action.
At any time during the processing of user input, one or more view operations can be invoked at 29b. In one implementation, the view operations supported are normal, preview, play, and zoom (at various zoom percentages). If any of the zoom levels are selected, the build tool initiates the dynamic web page resizing process at 29c (See FIG. 22). If the preview or play view operations are selected they will initiate the run time process (See FIGS. 28 through 36). FIG. 4a shows a run generation and runtime tool 370 at the detailed component level. The run generation and runtime tool 370 includes a run generation procedure 371, web scaling engine 372, a database 374 and a (web) page size generation engine 376 and run time engine 377 including a runtime user interaction engine 378, a runtime timeline engine 380 and a runtime drawing, animation, audio, and video engine 382. In one implementation, run time engine 377 includes plural engines, each of which may in themselves include plural engines.
FIG. 4b shows the run processes including methods for creating the run time files, including the external database, the web site specific customized run time engine, the HTML shell file, and the compressed CAB/JAR file. The run processes also include methods for scaling each web page to the web surfer\'s then current screen resolution and web browser window size. After a web page has been scaled, a run time engine executes a multi-level thread technology, which presents to the viewer web pages that can operate under time lines that may include animated transitions. Associated with the web page time lines can be object time lines that may define entrance, main and exit animations, transformations, and synchronized time lines for child objects. Each object can have multiple object states, responsive to various user interactions, which can result in numerous types of visual and audio responses and actions.
Referring now to FIGS. 4a and 4b, a run generation process 360 begins by invoking the run generation procedure 377. The run generation procedure 371 begins by creating the external database (part of database 374) at 30. The external database may include references to image, video and audio files, and video and audio channels. The process for creating the external database is described in greater detail below in association with FIG. 24. A customized and optimized run time engine (run time engine 377) is created at 31. The customized and optimized run time engine (run time engine 377) generates the web pages for the web site and is activated from the user\'s server. The process for creating the run time engine 377 is described in greater detail below in association with FIG. 25. The HTML shell file is created at 32, and then the CAB and JAR files are created at 33a. The HTML shell file includes JavaScript Code to activate and interrogate the page size generation engine 376, and to activate the entire runtime engine. The CAB and JAR files both include the runtime engine and database in compressed executable form. The CAB file(s) will be activated by the HTML shell file if it senses the browser as being Microsoft Explorer, otherwise it will activate the JAR file(s). The processes for creating the HTML shell file and the CAB and JAR files are described in greater detail below in association with FIG. 26 and FIG. 27, respectively. The run generation process portion of the run processes is completed as the HTML shell file and the CAB and JAR files are uploaded to the user\'s web site at 33b.
After the upload, the run time process 365 portion begins with the run time engine 377 invoking a web page size generation technology (engine) 376 at 34. The web page size generation technology can be used to determine the screen resolution and the current browser window size. The process for invoking and initializing the web page size generation technology is described in greater detail below in association with FIG. 28. The external database is read and the necessary objects generated at 35 from their stored external references. These objects include image, audio, and video objects. The processes for generating the necessary objects are described in greater detail below in association with FIG. 29. A web page generation and scaling technology (web page scaling engine 372) is then invoked at 36. The web page scaling engine 372 can be used to reformat and scale objects that had been placed in a web page during the build process. The processes employed by the web page generation and scaling technology are described in greater detail below in association with FIG. 30. The run time engine then, as necessary, executes a multilevel web page and object thread technology at 37 while the runtime user interaction portion 378 of run time engine 371 responds to user interactions at 38. The processes invoked by the multilevel web page and object thread technology are described in greater detail below in association with FIGS. 31-35. The processes invoked by the run time engine to respond to user interactions are described in greater detail below in association with FIG. 36.
Detailed Build Processes
Referring now to FIGS. 3a and 5 through FIG. 22 the build tool 350 and its associated build process are described. Referring first to FIGS. 3a and 5, initialization methods are shown. At 39 the build tools are created as part of the execution of the installation program 368. They can include:
1: Initial build tool HTML/JavaScript file (IBTF)
2: An initialization engine (IE).
3: A build engine.
4: The build engine parent HTML frame file. (PFF).
5: A Control Panel and Status Line HTML/JavaScript File (panel) for;
Controlling the JavaScript database.
Calling and initializing all pop-up windows.
Reading all pop-up window values, and updating a JavaScript database
Calling the build engine and passing all necessary data and status information.
Polling the build engine for two-way JAVA/JavaScript communication.
Displaying and updating the status of its interface objects.
Issuing alert messages.
Processing direct user interactions with the panel\'s interface objects.
6: Numerous HTML/JavaScript files, one for each pop-up window.
7: JAVA applets, embedded in HTML/JavaScript pop-up window files.
8: A build engine HTML definition file that is created and modified dynamically.
The initialization and build engines can be placed in a JAVA wrapper so that JavaScript code may receive and process return values from JAVA methods. The initialization and build engines are also created in a Signed CAB file, and assigned the necessary security rights, so that the engines can assert the necessary permissions, if permitted by a given browser\'s security manager, when read or write operations are required. In one implementation, an installation program is run prior to the first use of the build tools. After installing all of the files, the installation program can install the necessary class libraries required by the run generation process in which the customized and optimized run time engine is created (See FIG. 25). The installation program can also set the necessary environmental variables and installation options.
At 40 the web surfer points a browser at (i.e. calls) an initial build tool HTML/JavaScript file (IBTF). At 41 the IBTF identifies the current browser type and version number. Presently, each browser has different security manager implementations. In one implementation, the invention supports the following three categories:
1: With appropriate signing and time stamping, and with appropriate assertions of permissions, the browser will permit local read/write operations.
2: With appropriate signing and time stamping, and with appropriate assertions of permissions, the browser will permit local read operations, but write is only legal if sent to a server.
3: Local read/write operations are illegal, but are permitted on the server. The IBTF can include a flag that can be set to indicate which security implementation is supported, so that all subsequent read/write operations will comply with the current browser\'s security manager.
At 42, the IBTF causes the browser to execute the IE so as to sense the screen resolution and for adapting the interface to the user\'s screen resolution. In one implementation, after entering a delay loop and waiting for the IE to report it is fully loaded and initialized, the IBTF calls two IE methods, which return the width and height of the current screen and browser window. The IBTF then checks for the presence and value of a mode cookie, to determine whether this is an initialization process, a web site open command process, or a dynamic web page resizing process. If the mode cookie is set to initialize, or it doesn\'t exist, the IBTF calls the IE to generate the build engine\'s HTML definition file. At 43 the IE then asserts the required security permission and at 44 creates a build engine HTML definition file and writes this file to the local disk (as appropriate). At 45 the IBTF then turns control over to the PFF for activating the paner and build engine and displaying the build engine user interface screen.
The build engine user interface screen includes a panel portion and a build engine portion, each of which are loaded into their respective frames, after which the web site page(s) build process can begin. Screen shot FIG. 37 shows a representation of the user interface presented by the build tool. The user interface includes a panel 400 and build frame 500. Panel 400 includes a menu bar 410, menus 420 and sub-menus 430, tool bars 440, status fields 450, interactive fields 460, interactive pull down lists 470 and operational pop-up windows 480. The menu bar 410 can be used for selecting a menu command that will cause a menu to be drawn. The menu (one or menus 420) can be used to select a feature command that could cause an operational pop-up window to be drawn, a direct user input technique or object manipulation technique to be activated, or a sub-menu 430 to be drawn. A sub-menu (one of sub-menu 430) can cause the same type of events as that of a menu. The tool bars 440 include various icons that are shortcuts to feature commands that are also available through the menu bar and its menus. In addition, the tool bar 440 can be used to show the current state of a feature. Status fields 450 show the current value of a certain setting. Interactive fields 460 also show the current value of a setting, but can also be directly changed by the user by typing into the field, with the result immediately processed by the build engine 352 and displayed in the build frame 500. Interactive pull-down lists 470 also show the current value of a setting, but, if selected with a mouse click, will drop down a selection list, which may have an elevator attached. The user can click on an item in the selection list, which will become the current setting with the result immediately processed by the build engine 352 and displayed in the build frame. Operational pop-up windows 480 can have tabs assigned if the number of choices within the pop-up window is large. One or more settings can be changed through a pop-up window, with the results immediately processed by the build engine 352 and displayed in the build frame 500. These interface techniques are described in greater detail below in the build process.
The build frame 500 is used to present the actual web page as constructed by a user. The user can directly enter text, import images, video and audio for display/playback and create animations and transformations that can be viewed in the build frame. FIG. 6, with its attendant screen shots FIG. 38 through 48, shows the user input techniques supported in one implementation of the invention. In one implementation, the user inputs supported include: selection from a JAVA window object (48); selection from a JavaScript window (49) including selection with dual spin control (50a) or selection from a JavaScript child window object (50b); direct text entry (51); page resizing (52); direct object manipulation (53); and, selection from a JavaScript panel (54).
In the implementation shown, of the six user input techniques sensed at 13, the code for supporting selections from a JavaScript pop-up window at 49 and selections from the panel at 54 were implemented entirely in HTML/JavaScript Code, while support for direct text entry at 51 and direct web page object manipulation at 53 were implemented entirely in JAVA (or any other browser-based full featured programming language). In one implementation, code for supporting selections from a JAVA Window object at 48 and dynamic web page resizing at 52 are implemented using both HTML/JavaScript and JAVA. Those of ordinary skill will recognize that, JAVA could have been used more extensively to implement the methods described at 48, 49 and 54. However, in order to achieve the most intuitive and MS Windows like interface, and because effective two-way communication between JavaScript and JAVA had been achieved (See FIG. 9), the languages proposed appear to best support the particular user input technique.
For example, FIG. 23 shows an actual file selection window 2300, implemented by the invention. This type of file selection window is available in JavaScript/HTML, but not supported by JAVA for applets. File selection window 2300 greatly enhances the interface for the user, as the image, sound clip, or video clip names need not be memorized. File selection window 2300 further eliminates possible operator error when typing in a pathname or filename. The present invention utilized the strengths of JavaScript/HTML with the power of JAVA to create a unique browser based interface solution. In one implementation, the HTML form element INPUT typefile was embedded in a JavaScript pop-up window to create the file selection window. The file selection window returns a string value of the image (or other file type) pathname to the pop-up window. The pop-up window\'s JavaScript then could be used to call a JavaScript function in the panel (panel 400) which:
1: Reads the pathname value in the pop-up window.
2: Creates a string version of a valid URL by adding the correct URL protocol to the string.
3: Updates the panel\'s database (interface\'s database 360).
4: Calls a JAVA method in the build engine, which casts the string value of the URL into a URL object, creates an image object which is then drawn on the screen, and updates its internal database.
User inputs that are a selection from a JAVA window object (48) permit the implementation of a vast array of intelligent user input interface objects, from sliders to dials, which are extremely intuitive and significantly enhance the user\'s ergonomic experience. In one implementation, user input interface objects are supported as follows. When a selection from a JAVA window is detected, a pop-up window (applet) is presented (associated with the feature being manipulated, e.g., color, volume) and an engine method is called to begin two-way communication (for passing as arguments any necessary status information). The engine begins polling a JAVA abstract object waiting for a static variable\'s value to change. The pop-up applet processes the value as defined by a user interaction event, and updates the static variable in that same JAVA abstract object with the new value. Upon detecting a change in the polled static variable, the engine calls the necessary methods to process that new value. These methods include can include a brightness filter that is applied to the image bitmap utilizing techniques very similar to that of that employed by the fade in and fade out animations, described in association with FIG. 33
User inputs for a selection from a JavaScript pop-up window (49) can be made in a manner identical to that of making a selection from a dialog box under MS Windows, including the use of tabbed JavaScript pop-up windows. In one implementation when a selection from a JavaScript pop-up window is detected, the panel\'s (panel 400) JavaScript opens a pop-up window. The pop-up window\'s initial values are set from a JavaScript database defined in the panel or by the panel calling the engine for the current values and then setting the initial values. In a tabbed JavaScript window, clicking on a tab will call the pop-up window\'s JavaScript in order to change the state and appearance of the tabbed JavaScript window in the expected way. The pop-up window\'s JavaScript calls the panel\'s JavaScript when a completion event occurs. The panel\'s JavaScript reads or the pop-up window\'s JavaScript writes the pop-up window\'s field values, causing the panel\'s database to be updated, and the panel then calls the appropriate build engine 352 method, passing as arguments the necessary data and status conditions. Initializing the pop-up window\'s values and updating the panel\'s database upon completion can alternatively be implemented by JavaScript functions executed within the pop-up window\'s HTML file.
In addition, there are interface extensions that can extend beyond the usual MS Windows implementations. One is support for a selection from a dual spin control at 50A. Screen shots FIGS. 42-45 show a visualization of an implementation of this interface technique. Screen shot FIG. 42 shows the mouse placed over an upper spin control. Screen shot FIG. 43 shows the result after the user clicked once on the upper spin control. Notice that the value has been incremented by 1, and the text button object is now at a larger point size. Screen shot FIG. 44 shows a combo box list selected by the mouse with the user about to select a significantly larger point size. Screen shot FIG. 45 shows the result of that selection, including the effect on the text button object.
In one implementation, dual spin controls are supported as follows. Each spin control has three visual states, so that when the user places the mouse over the control it appears to light up, and when the mouse button is depressed (pressed down), the spin control is modified to give the appearance of being pressed. JavaScript methods are called in the panel (panel 400) to:
1: process each mouse click event over either spin control,
2: range check as necessary,
3: update the value in the HTML frame object residing in the pop-up window,
4: update the JavaScript (panel 400) database,
5: call the build engine 352, if necessary, passing the necessary value and status.
If the mouse is clicked on a combo box, the selection window opens in the usual way. If a mouse click in that window is detected, another JavaScript method in the panel 400 is called to update the JavaScript database, and call the build engine 352, if necessary, passing the necessary value and status as function call arguments.
Another interface extension is selection from a JavaScript child window at 50B. This technique helps simplify the number of choices given to the user in a complex pop-up window operation. A selection from a JavaScript child window can be supported as follows. The panel\'s (panel 400) JavaScript opens the pop-up window. The pop-up window and its child pop-up windows\' initial values are set from the JavaScript database defined in the panel 400. The pop-up window\'s JavaScript opens the child pop-up window and sets its initial values. The child pop-up window\'s JavaScript calls the pop-up window\'s JavaScript when a completion event occurs. The pop-up window\'s JavaScript reads the child pop-up window\'s values, sets those values to its own internally defined variables, and calls the panel\'s JavaScript. The panel\'s JavaScript reads the pop-up window\'s values (which include the settings for its own fields as well as those of its child windows), updates its database, and calls