Table of Contents
Fundamental principle of Interactive Geometry Software is: geometric objects of a construction maintain their mathematical relations under mouse operations or driving data changes.
Figure below shows a construction of the circumcircle of a triangle. Manipulation of any vertex in the construction will cause the circumcircle to be updated accordingly.
Google Docs vs. Microsoft Office is a typical comparison between Web-based system and traditional desktop-based system.
We can easily list some desirable features a Web-based Interactive Geometry authoring system should have.
-
No software installation
-
Fast loading and fast initialization. If it takes to much time to load, there is no advantages over desktop-based systems. Almost any systems using Java technology partially fail this condition ths first time they run.
-
Fast interaction response. Interactive Geometry Systems are computation intensive, and interaction intensive. The performance of a Web-based system should be almost as good as a desktop application.
-
A geometry construction is saved on the server side, and can be created, accessed, and modified from anywhere.
-
Easy publishing and sharing.
-
Easy searching for useful constructions
-
Scripting support to allow interaction between the construction and the enclosing HTML page. We don't want a construction in a page to be an isolated part. We want to retrieve data from within the construction or drive the construction by contents in the enclosing page.
HTML/SVG/JavaScript together are an ideal environment to meet the above requirements.
-
The GeometryEditor toolkit:
-
An SVG-coded Plane Geometry Engine for authoring and viewing construction (creating, moving, and animating geometric objects).
-
GUI for the authoring environment providing authoring logic, a variety of dialogs assisting authoring, publishing, and communications with the server side.
-
-
The GeoSite (demo site: http://boar.cs.kent.edu/geosite): a Web site that makes the GeometryEditor toolkit available as well as stores manipulatives for access, searChing, and sharing.
While the engine provides the core functionalities for GeometryEditor, the GUI makes user control simple and intuitive, an important requirement especially for teaching and learning.
Since GeometryEditor runs in a browser, its GUI depends on the widgets made available by the browser to a Web page.
At the early development of GeometryEditor, the GUI implementation was greatly affected and limited by the browsers’ SVG capability.
In 2004, the only way to view SVG was to use Adobe SVG Viewer plugin to work with browsers on Windows, Linux and Mac. The problem was that except on Windows IE, the plugin lacked the ability to communicate with the enclosing HTML. I had to develop menus, toolbars and dialogs all in SVG. And the GUI communication with the GeoSite had to be implemented using Adobe SVG Viewer’s getURL/postURL , which was a non-standard extension for SVG.
In May 2005, Mozilla Foundation released Firefox 1.5 Alpha, which is the first browser to have native support for SVG. The SVG-HTML cross communication problem is gone. Standard Ajax technique can be used instead of plugin’s non-standard extension. Furthermore, With Firefox, we can also utilize widgets made available in XUL (XML-based User Interface Language) including different menus, listboxes, trees, and tabboxes. Further, our GUI implementation uses XBL (Extensible Binding Language) for creating user-defined widgets. I started to migrate the GUI of GeometryEditor using Firefox’s XUL and XBL technology.
In 2007, Opera 9 started to support SVG natively, and so did Safari 3.1 in March 2008. SVG was well accepted and adopted by major browsers except only Microsoft Internet Explorer. In order to make GeometryEditor be compatible with Safari and Opera, I started to use HTML/CSS to develop the GUI.
The GUI works closely with the Geometry Engine. Some GUI widgets need users to select objects from the canvas controlled by the Geometry Engine. Some GUI widgets activate some actions or events in the Geometry Engine.
GeometryEditor uses many SVG elements for geometric object rendering. All the SVG elements are dynamically generated by user interaction. For each geomemtric object, there is a group of SVG elements for rendering the object, highlighting the object, indicating user selection of the object and the label of the object.
Regarding capturing object event, such as mouse on a geometric object, SVG doesn't provide enough help. If two SVG elements overlap on the canvas, the mouse event at the overlapping area can only return the object that is added to the DOM tree later. GeometryEditor has its own algorithm to determine if a mouse is on more than one object simultaneiously.
GeometryEditor is very user interaction intensive and computation intensive. Whenever a top level object changes the position by the user, the position of all the objects determined by this object have to be recalculated. The SVG supports by major browsers are all good enough for pretty complicated geometric constructions.
GeometryEditor defines a set of APIs to access a construction by the enclosing Web page. A construction is no longer an isolated part in a Web page. Interaction between a constuction and the enclosing page, or interaction between two constructions becomes possible.
Following list some possible interactions.
-
The enclosing HTML page retrieves data from the geometric construction, and updates some HTML contents.
-
A MathML section retrieves data from the geometric construction, and updates the MathML contents. In this example, this MathML section is also one kind of construction generated by another authoring tool called MathEdit. GeoSite is able to host not only GeometryEditor, but also other authoring tools that follow some standards.
-
The position of some geometric objects in the geometric construction are determined by contents from the enclosing HTML.
-
Changes one geometric construction can affect another construction
