Providing input when solving a mathematical problem in a technology-enhanced learning system is often a challenging task for a learner. Input editors either provide clickable palettes to construct terms, or require knowledge of some linear syntax. To alleviate this problem, the learning environment ActiveMath was extended with a new interface supporting learners with providing a stepwise solution in the fraction domain. The interface allows learners to insert intermediate steps using pre-de ned templates such as \The least common multiple of and is ", where a blank can be lled in using a dedicated simple input eld. Developing similar interfaces for other mathematical domains is labor intensive and error prone. In this article, we investigate how the Ideas domain reasoners can be used to derive the necessary information for the automatic generation of such templates, by making the structure of domain rules explicit using OpenMath expressions.
The question of how to design a user interface for interactive problem-solving is central
to technology-enhanced learning environments. Depending on the level of sophistication
of the system, the input mechanism for a learner ranges from a single blank eld to input
a solution to carefully designed forms that can be considered to provide support by their
structure. Building such elaborate input templates is a tedious task, and requires a
thorough analysis of the domain and expertise in interface design. In the case of Angle,
a cognitive tutor for geometry [
For mathematical domains involving formul , designing this interface becomes even
more delicate given the complexity of formula input per se. Although mathematical
input editors such as MathDox and Wiris are widely used, their application in learning
environments still raises usability issues, as they typically require typing some linear
syntax, o er palettes for the construction of formul , or allow a combination of these
approaches. This places extraneous cognitive load [
The user interface may also have a more general impact on the potential e
ectiveness of a tutoring system. VanLehn [
We have developed an interface for stepwise input of problem solutions based on templates that embody general methods used in that domain (e.g. expansion of fractions for fraction problems), which we describe in more detail in Section 2. While the templates are domain-speci c, the approach of decomposing a problem into sub-steps is more general and should at least transfer to domains with an algorithmic character. In Section 3, we characterize the essence of sub-steps in our interface. After introducing the Ideas domain reasoners in Section 4, we present an example of automatic sub-step extraction. Finally, we discuss problems we encountered and raise questions for future work. 2
The Steps interface is part of the web-based intelligent learning environment
ActiveMath [
When an exercise is started, a learner is presented with a single input blank that can be used to supply the overall solution. The basic idea is that the learner inserts as many steps as she needs using an interactive element referred to as a line, which allows the manipulation of intermediate steps. A line consists of a drop-down menu from which the learner selects a description of the intention of the step. The menu-items are the operations that are relevant in fraction-addition problems: expand, reduce, nd prime factors, nd common denominator, compute inverse, transform, add, subtract, multiply, divide, nd least common multiple, and nd greatest common divisor. After selecting an operation, a corresponding template to be lled in by the learner is inserted in the line. For instance, if the learner chooses expand fraction, she will get the template \ expanded by is ", as shown in Figure 1. Steps are added or removed by clicking on the corresponding buttons on the right.
This approach decouples the learner's intention (e.g., expanding a fraction) from the actual execution (e.g., computing the expansion step) and eliminates the need for heuristics to guess what the learner is trying to achieve. The separation of intention and execution is useful for the system to interpret the learner's input. In addition, by the introduction of sub-steps, the complexity of input to be entered in one single blank can be reduced (e.g., 2+3=5 vs. 2 + 3 = 5 ). We replaced the complex input editor usually available in ActiveMath with a dedicated light-weight text eld replacement supporting input of numbers, basic arithmetic operations as well as fraction input. 3
A template represents the application of a domain method. It has a descriptive name (such as add) which is displayed in the drop-down menu. The representation of the template consists of a formula or text interspersed with blanks to be lled in by the learner. This simple format supports the learner at multiple levels by pre-structuring the input format.
A template contains structural information about the represented method. The add template, for instance, is + = , which makes it easy to identify summands and the result. Making the + explicit in the template structure gives away that an addition term should contain a + symbol, which in this case is a trivial fact. Distributing the input of the addition term over two blanks reduces the chances of learners struggling with typing mistakes. Still, one has to be careful with the amount of guidance o ered by structural help. It can be tempting to create templates that do more than just making input more comfortable or interpretable. The following template for one of de Morgan's laws can certainly be considered as a form of sca olding for a learner who is not familiar with it, but might not be appropriate in all situations: :( ^ ) = _ .
Another more subtle form of structural support is obtained by o ering a particular input editor to the learner to ll in a blank. A template, in addition to making structure explicit by means of showing blanks, also contains implicit knowledge about the type of input that is expected. In the template \ expanded by is ", it is relatively clear that the rst and last blanks should be lled in with fractions, while the second blank should be lled in with a number. This type information can guide instantiation of the blanks: blanks expecting numeric input could be rendered with a very simple input editor, while a blank in a derivative exercise to be lled in with an elaborate function expression could be rendered using a palette-based editor such as WIRIS OM1.
A template also embodies a certain step granularity. Consider the task of solving a quadratic equation. We could have a single template for the application of the quadratic formula, representing an equivalence with the equation on its left-hand side and the solution set on the right-hand side. An alternative to such a template for a big step could be to de ne additional templates for the sub-steps of applying the quadratic formula: (i) identi cation of a, b, and c, (ii) computation of the discriminant , and (iii) speci cation of solutions. In this way, sets of templates can be used to allow a learner to work on di erent levels of granularity. Adding templates for algebraic manipulations to the example above would further expand a learner's freedom by allowing the usage of various strategies (e.g., clever factorization).
Templates do not only support learners, they also enable ne-grained diagnostics in the system. A template lled by the learner carries valuable information, such as the intention of the learner, derived from the selection of the template, and the instantiation of the domain method, derived by the lled in blanks. More elaborate information such as correctness, applicability conditions, and strategic cleverness could be computed from the template by domain reasoners. 4
The Ideas domain reasoners are constructed around rewrite strategies [
The granularity of steps is an important design consideration in a domain reasoner.
The compositional speci cation of strategies allows for coarse-grained steps that combine
several rules. For ne-grained steps, views [
Consider the exercise to compute 72 + 12 from Figure 1. The worked-out solution generated by the fractions domain reasoner for this exercise is: = = = 27 + 21
fexpand by 2g 144 + 21
fexpand by 7g 144 + 174
fadd fractionsg The derivation does not show that the domain reasoner starts with an implicit step that computes the least common multiple of the denominators. This multiple is then used for determining how to expand both fractions. The rewrite rule for expansion, a b ! abcc with c 6= 0, is parameterized over the expansion factor (meta-variable c) since it does not appear on the rule's left-hand side. The rewrite rule for adding two fractions, ac + cb = a +cb , also performs the addition of two numbers in the numerator. 5
The derivations generated by Ideas and the structured solutions that can be produced using Steps share similar characteristics. We postulate that this similarity can be exploited to generate domain-speci c templates for the Steps interface from Ideas semi-automatically, and even fully automatically for certain domains. In the remainder of this section, we propose an approach to extract templates from a simple domain reasoner for fractions. We rst reconsider a part of the fraction example from Figure 1 and make the ingredients of templates more explicit. The template used in the rst line contains information about the semantics of the step. It represents the application of expansion of fractions to two arguments, and establishes an equality statement between this and the result (the third argument). In addition, it constrains the input by using our simple input editor for numerical input to ll in the blanks.
We represent a template as an OpenMath object. The OpenMath standard is a suitable choice for exchanging information about templates, as it allows us to express <template name="Find LCM"> <typemap> <typeof varname="a" typename="Integer"> <typeof varname="b" typename="Integer"> <typeof varname="c" typename="Integer"> </typemap> <OMOBJ> <OMA> <OMS cd="relation1" name="eq" /> <OMA> <OMS cd="arith1" name="lcm" /> <OMV name="a" /> <OMV name="b" /> </OMA> <OMV name="c" /> </OMA> </OMOBJ> </template> the semantics of the template, and, if necessary, to de ne new symbols that can be used to convey the intended meaning of a template. Figure 2 shows the OpenMath representation of a template for nding the least common multiple.
The OpenMath object in Figure 2 represents the equation lcm(a; b) = c. To obtain a template, the variables in this equation are replaced by blanks. The variable names can also be used to identify the blanks in further communication between the learning environment and the domain reasoner, for instance to provide feedback about the correctness of the blanks lled in by the learner. Information about the types of the variables is stored in a type map, which is used for selecting the input editors for the blanks.
The rewrite rules of Ideas can already be represented as Formal Mathematical
Properties (FMPs) in OpenMath [
\a b -> lcm a b :~> lcm' a b expandRule :: RewriteRule Expr expandRule = describe "Expand by" $ makeRewriteRule "expand" $
\a b c -> expand (a / b) c :~> (a *! c) / (b *! c)
These de nitions make use of a Haskell library for datatype-generic rewriting in Haskell [
Because precise control over the granularity in the generated templates is needed, we expect that adding annotations cannot be fully avoided. Hence, template generation will be semi-automatic. The domain reasoners are extended with the new ruletemplate service that given a rule returns a template.
To render the OpenMath-based template representation as Steps templates in the User Interface, we replace the previously hard-coded templates by a call to a new service providing a list of available templates. This list is obtained by parsing template descriptions as returned by the ruletemplate service. Labels are extracted from the name attribute of the top-level template tag.
The current implementation assumes to nd the application of relation1/eq at the top level of the OpenMath expression to identify left- and right-hand sides. For each of these expressions, OpenMath symbols are presented using pre-authored presentations encoded in the system. OMVs are transformed to blank placeholders containing type information extracted from the typemap. When the template is nally requested for presentation, these placeholders for blanks are replaced by the actual HTML/JavaScript code for the required mathematical input editor. 6
In this paper we have discussed domain-speci c templates for supporting the input of intermediate steps in mathematical exercises, and how these templates can be generated semi-automatically from rule speci cations in the Ideas domain reasoners. The generation of templates is based on the close correspondence between the explicit rewrite rules and the implicit calculations in the domain reasoner on the one hand, and the small interaction granularity in the Steps interface on the other hand. The canonical forms that are used in the domain reasoner's rewrite rules can provide enough information about the structure of the templates, as well as the types of the blanks. We have proposed a representation for templates based on the OpenMath standard.
In the future we want to explore whether automatically generated templates providing various levels of structural support can be used for adaptive sca olding purposes. This could be particularly useful for domains involving term rewriting such as algebraic manipulation of mathematical expressions. We also want to investigate how we can make the tree structure underlying many problem-solving processes more explicit. Another line of research we will follow will focus on using domain reasoners to interpret learner input. Templates extracted from the domain reasoners contain enough information to run ne-grained diagnostics which will allow precise identi cation of the learner's problems.
Finally, we will investigate how blank locations and types at suitable granularity levels can be automatically derived from rewrite rules and rewrite strategies in existing domain reasoners.
We thank the reviewers for their useful comments and suggestions. Eric Andres' visit to Utrecht was partially funded by the Utrecht University Research Impulse Educational and Learning Sciences.