Senior Project – I.D. Math & Computer Science jsMath Equation Editor Dana Cartwright Advisors – Prof. Cervone & Prof. Striegnitz Editor Design - Features Edit-In-Place Arrow Navigation The editor has support for moving the cursor using all four arrow keys, allowing advanced users to rapidly edit equations using only the keyboard. Mouse Placement Sometimes users may want to use the mouse to position the cursor, especially when things get complicated: In the editor, the user’s cursor is right in the equation, and typing is translated directly into mathematics in-place. Mouse Selection Users can drag the mouse in the editor window to create selections of a group of text, as well as creating selections using the keyboard. Then, for instance, hitting the [/] key would turn this selection into the numerator of a fraction. Architecture & Technology The editor is written entirely in JavaScript, which allows the bulk of the work to be done client-side. The only server communication that is needed is for the jsMath display package to dynamically load images from the server if the TeX fonts are not installed on the user’s computer. Because of the JavaScript architecture, this editor is uniquely suited to be embedded into AJAX applications like WYSIWYG (What You See Is What You Get) online HTML editors, increasingly popular for easy-to-use CMS (Content Management System) editing. This would allow non-tech-savvy users to easily create web sites which included mathematics or other typeset equations, particularly useful for mathematicians and scientists who wish to effectively communicate their ideas online. The jsMath display package takes TeX code and displays it as typeset mathematics in the browser. So, the editor outputs a modified form of TeX (we had to add things like cursors and other special formatting for use in the editor) to jsMath, which is then rendered on the browser page. JavaScript event “hooks” are embedded in this display code so that user interaction will be sent back to the editor. So when the user types with the keyboard or clicks the mouse, the editor determines what, if any, changes should be made to the equation, and then outputs the new TeX to jsMath. A diagram of this process is below: Implementation Examples Mouse Positioning In the above diagram, the colored boxes shown are bounding boxes for each element of the equation. Internally, these are linked via JavaScript events to nodes in a tree. So, for example, the right-hand purple box is around a minus symbol, which has a [z] node for a left child and a [5] node for a right child. A mouse click from the user is returned as an (x,y) position in relation to the node’s own coordinate system. So, if the user clicked between the minus symbol and the 5 symbol, the minus node would get the click in terms of the purple bounding box. Each node then knows about the bounding boxes of its children, and can determine the best cursor position (to the left or right of each of its children, in the minus’s case) based upon these. Up & Down Arrows Internally, up and down arrows are somewhat complicated to implement. Our solution involves “bubbling up” the arrow from the node that currently has the cursor to each of its parents in turn, trying to find one which “knows what to do” with the given arrow press. So, for example, a variable or number will pass on an up arrow, while a fraction will move the cursor into its numerator. Sometimes though, this can be ambiguous. In the example below, if the user were to press the up arrow should we go into the superscript of the [x^y] term, or into the numerator of the fraction? We solve this by keeping track of the last left/right arrow key pressed, and continuing to move in that direction. User Testing Motivations Most current editors use text entry with a parallel display. This results in a language that requires lots of parentheses and/or bracing in order to indicate grouping. The example below demonstrates an ambiguous case where such an editor would require bracing. So, one goal for the editor will be to have an edit-in-place paradigm that does not require excessive nested bracing or similar measures. Vs. Although almost all of the features we wish to implement our featured in current editors, no one editor combines them in a sensible way. We would like to put these features together into one editor which is easy to use for beginning users, as well as efficient for advanced users. In addition, most of the good editors out there are proprietary and expensive. This means not only that they are not accessible to all users, but also that it is impossible to embed them in other projects or extend them to export to other editors, for example. By creating an effective open source editor, we solve these issues. In order to test our design, we conducted preliminary HCI testing on our proof-of-concept editor. Our main goal in this testing was to test features, and not to determine overall suitability of the editor. In particular, our testing was not aimed at making any claims about the efficiency or ease-of-use of the editor in relation to other editors, or even in general. Below are some of the features we set out to test, and some example exercises the users were given in order to test them. Mouse vs. Keyboard Selection One goal of our test was to determine if users preferred to use the keyboard or the mouse to create range selections. Below is an example trial designed to be much easier if the user uses a range selection (they can simply select the entire equation end then hit the [/] key to create the division). We evaluate this exercise based upon whether the user selects via the keyboard, the mouse, or the long way around by deleting the whole thing, creating the division first, and then re-typing it. Given:Goal: Preferred Cursor Movement Method During the training exercises, the user is given the choice of whether or not to use the Fast Cursoring feature, which causes left/right arrow key movement to skip over things like fractions, requiring the user to use the up and down arrows to enter into fractions. The following exercise was designed to determine if this feature was beneficial or harmful to users’ efficiency (or whether they just liked the mouse better, and placed the cursor directly). The key here for the user is to move the cursor into the denominator of the denominator of the second fraction, as they must add a [+ x] term to it. Given: Goal: