Few systems exist that support learners explicitly in the process of learning mathematical generalisation. This paper presents the eXpresser, part of a new system that seeks to address this issue by providing the user with a microworld for the construction and analysis of general patterns. The design includes the provision of sophisticated intelligent support that assists learners and teachers throughout their various interactions with the system. Given the open and exploratory nature of the environment and the resultant freedom it affords, integrating such intelligent support poses a significant research challenge. This paper describes the system in detail and discusses a variety of ways in which we intend to meet our research goals for providing intelligent support.
This paper presents the eXpresser, a mathematical microworld in which users
can build and analyse general patterns. Within this microworld, the user can
explore, experiment, and, through developing their own models, actively
construct their own understanding of the idea of mathematical generalisation. The
eXpresser is part of a larger system that is being designed and developed by
the MiGen Project.3 The aim of the project — to improve the mathematical
generalisation abilities of 11–14-year-old children — addresses a real need in
secondary mathematics education since many students in this age-range perceive
generalisation and indeed algebra as difficult and unnecessary with no relevance
to the way in which they approach problem-solving (as discussed in [
Despite this significant problem, a paucity of systems exist to help children embrace algebra and understand its power. The MiGen Project is seeking to 3 See http://www.migen.org/ for more details. Funded by the TLRP, e-Learning
Phase-II; grant number: RES-139-25-0381
address this issue and, in the light of research that suggests that significant
pedagogic support is needed for the student during their interaction with such
environments (see [
As important (and perhaps more importantly), the philosophy behind the development of the system is not to replace teachers but to support them. As a result, all components of the system will provide appropriate potentially-intelligent interfaces for the teacher to assist them in their goals for the lesson and to integrate the system into the classroom context.
After a brief discussion of related work (Section 2), Section 3 presents the current version of the system in detail as a basis for discussion in Section 4 of the potential for intelligent support, both for the student and the teacher. 2
Several learning environments have been developed and integrated in classroom
contexts over the last few years that attempt to help students in algebra and
problem-solving. However, most of them expect students to have a clear notion
of the concept of variables and an understanding of algebraic notation.
Therefore, they do not deal explicitly with the difficulties students face when they
are involved in generalisation (for a review of these difficulties see [
Closest to our work is research on mathematical microworlds [
One successful approach, in relation to generalisation from patterns enables
students to engage with models that they are constructing themselves. For
example, in Mathsticks [
The aim of our project is to develop tools that provide assistance to
learners and advice to teachers based on analyses of students’ interactions with the
system. The rationale behind this aim is that the freedom of exploration in
microwords entails the risk that the student may not ‘accept or notice the
educator’s agenda’ [
Despite the existence of intelligent tutoring systems that attempt to help
students with algebra (e.g., [
Earlier iterative development towards the eXpresser developed ShapeBuilder, a prototype microworld for exploring generalisation. Although many of its features were pivotal to our thinking, ultimately, the underlying engine was not applicable to many typical generalisation tasks within the National Curriculum. This is due to the fact that many such tasks make use of the notion of repetition within patterns. Figure 1 shows two typical problems, the ‘footpath’ which is a repeated tiling and the ‘pyramid’ which not only makes use of repetition but repetition with changes since each layer increases in size relative to the previous layer. (a) (b) (c) (d)
When investigating such tasks, students would typically be asked to work out its general structure so that they could describe other instances of the pattern. In the case of the footpath, for example, they would be able to describe what it would look like if it had 10 (dark) blue squares surrounded by (light) green squares and, similarly, in the case of the pyramid, what it would look like if it had 6 layers. In addition to this, students are also usually asked to investigate questions such as the general rule for the number of green squares needed to surround any given number of blue squares in the footpath pattern.
Following from these observations, the eXpresser provides an exploratory environment that allows the user to construct their patterns freely and analyse these constructions so as to obtain interesting general rules. Figure 2 shows the current interface and briefly describes each of the available tools.
Cut/copy/paste to/from the clipboard.
Delete.
Zoom in/out.
Set the visibility and size of the grid.
Group/ungroup.
Change/Select colour.
Unpattern.
Create a row/column pattern.
Demonstrate a pattern. The user is able to create a ‘unit pattern’ which looks like a single block. However, inspecting its properties reveals that it is in fact something more complex as illustrated in Figure 3a. The property box in this figure shows three numeric attributes, each of which has an icon. The cogs icon specifies the element count of this pattern. The cogs icon with the right arrow specifies how far to the right each shape should be from its predecessor and, similarly, the cogs icon with the arrow downwards specifies how far down a shape should be from its predecessor. Initially, the element count of a pattern is 1 and the other attributes 0 but by setting these values appropriately, various basic patterns can be obtained. Some of these are shown in Figure 3b–e. Although interesting patterns can be created using such a basic mechanism, the underlying engine is far more powerful since a pattern can be based on any shape whether it is a pattern itself or a group. Currently the interface provides three ways in which to access this generic facility: creation of a horizontal sequence, creation of a vertical sequence and creation based on a ‘demonstration’ of the first two elements. These first two elements implicitly indicate what happens from one element of the pattern to the next. Using this information, the system is able to create the pattern. For example, given two shapes with attributes as shown in Figure 4a and Figure 4b, specifying 4 to the demonstrator tool (Figure 4c) results in a triangle pattern (Figure 4d).4 3.3
With the facilities described so far, the user is able to build complex patterns with ease. However, there is also a need to make patterns depend on one another. For example, consider the case where the user is constructing the footpath pattern. If they decide to work row by row, they may first create a pattern of blue squares as shown in Figure 5a. The number of green squares needed on that row is one more than the number of blue squares. By naming the first pattern, this relationship can be specified iconically as shown in Figure 5b. The other rows of the pattern depend in a similar way on the number of blue squares as shown in Figure 5c. 4 Note that the two shapes used in this example also implicitly specify a movement downwards from one element to the next. At present, this is not shown explicitly in the attribute list so as to prevent user confusion. Being able to relate attributes of shapes in this way is fundamental to the construction process and through it, the power of generalisation becomes apparent to the user.5 Figure 6a shows how the pattern (as constructed in Figure 5) changes when the number of blue squares is changed to 5. As expected, the layout of the green squares changes appropriately, thus demonstrating the generality of the construction. In contrast, the construction in Figure 6b does not look correct since the number of squares in its top and bottom rows were specified in absolute terms when there were originally 3 blue squares. In the case of Figure 6c, no aspects of the construction are general; all parts of the pattern were created specific to when there were 3 blue squares.
For constructions that are not entirely general, changing the number of blues
in this example ‘breaks’ the pattern. This potential for ‘messing up’ [
The user next adds the surrounding green pattern for the middle row. Since the allocation for green is currently zero, these squares appear differently as 6 Note that the specification of the element count here is in terms of the blue allocation.
This differs from Figure 5a in which the element count was specified explicitly. shown in Figure 7d. The user can correct this by specifying the number of green squares that are now needed7 (Figure 7e). The remainder of the example continues similarly for the top row (Figure 7f-g) and the bottom row (Figure 7h-i). In this way, the user iteratively refines the expression for the green allocation, interleaving construction and analysis. Ultimately, the blue allocation now ‘drives’ the pattern in that changing its value results in a different instance of the footpath. Moreover, the green allocation is now the general rule for the number of green squares needed to surround the blue squares.
This example shows a very rigorously interleaved process of construction and analysis. The advantage here is that through this interleaving, the user may gain a deeper understanding of their construction. However, this comes at a cost in terms of requiring quite complex interaction with the task on two different levels. In view of this, the system is being designed so that if the user, teacher or task designer so desires, construction can proceed without a concern for allocations. Then, once comfortable with how to create the general pattern, the user can, in a subsequent phase, re-build their construction paying attention to the allocations needed. So, rather than interleaving construction and analysis, construction happens first followed by interleaved reconstruction and analysis.
In summary, just as ‘messing up’ provides the user with an incentive to generalise, allocations provide the user with an incentive to analyse. 3.6
One of the design criteria for the eXpresser and one closely related to the constructionist approach we have adopted is that the microworld should be expressive enough so that any given pattern could be constructed in a variety of ways. Such scope for alternatives allows the learner to realize how multiple valid solutions to a problem lead to different — but equivalent — expressions. There is then an incentive to develop intuitively some of the basic rules of algebra such as commutativity and associativity as well as provocation to collaborate with other children who have found correct but different solutions. Figure 8 shows two further constructions of the footpath. 7 We are in the process of elaborating this feature so that excessive allocations are indicated to the user appropriately.
As Section 3 explains, the system affords a variety of ways for users to interact
with tasks. These interactions between the system and the students are shown
diagrammatically in Figure 9 by the edges annotated with ➀ and ➁. Given the
inherently open and exploratory nature of these interactions, integrating
intelligent support within this process is a significant challenge (see [
➃ ➃ Teacher ➅
System ➄ ➄ ➀ ➁ ➂ ➂ ➀ ➁
Student A Student B Teacher
Student A
Student B
Students will be able to collaborate both during and after the construction
and analysis processes (➂) and, through intelligent modelling of the collaborative
behaviour of the students, the system will be able to recommend effective
pairings/groupings of students. Furthermore, there is also significant scope within
the system for the effective use of dynamic variation of the collaborative
affordances of the interface [
The teacher will interact with the system (➃) in order to create, design and deploy tasks and task sequences. They will also be able to affect the experiences of the students directly (➄) by recommending next steps, intervening or allocating further tasks. Most importantly, it will also be possible for the teacher to obtain summary information across all their students (➅). At its simplest, this can provide the teacher with an overall impression of class progress and, with the use of appropriate representations, can facilitate attending first to those who are most in need of help. Both these services can be greatly enhanced by the appropriate integration of intelligent support. For example, a summary of class progress could take into consideration all previous user experience and provide a much more accurate view. Moreover, with such a facility in place, it is possible to avoid situations in which students misunderstand certain concepts and leave a lesson with a false sense of achievement. This, in combination with other aspects of intelligent support, balances freedom and feedback, allowing students to play, explore, make mistakes, see the immediate outcome of their actions and learn.