This conversation about paint-flooding, tile-dropping, etc, looks to me like coming
back to the Manifester discussion, in which I thought we had reached a conclusion:
use the checker-manifester. Am I missing anything?

http://migen.wikidot.com/2008-05-07-task-meeting-notes

Another conclusion that I though was clear was the fact that the Manifester should
not be automatic. Richard was quite against ideas like robots laying tiles
automatically, super-speed dropping of tiles, etc. I thought everybody had agreed
that the Manifester (whether a tile-dropper, a tile-lighter, a tile-painter or
tile-checker) should follow the actions of the students; it should not have its own
behaviour. This is an idea in which we insisted along two or three general meetings,
or at least that is what I perceived. 

I am confused now, with this discussion. ?:-/

I thought Darren was suggesting that a checker-manifester like gadget be needed to 
generate a pattern (or at least color it in). The checker is something you run AFTER 
building a pattern. This is a prerequiste part of BUILDING the pattern the first 
time. Also the checker is a manual process, right? Quite different. Darren -- is 
this the difference between what you proposed yesterday and the checker-manifester?

I don't feel strongly whether you see a tile dropping entity like a robot or the 
tiles just appear (or whether ghost tiles appear and their colouring is animated).

BUT I'm surprised there was this decision against watching the tiles being dropped --
 this seems a great way of understanding the structure of a complex pattern.

I copy part of my comment at  Issue 240 .

"I am sorry I did not manage to make it clear. The wrong thing is the "magic" in the
manifesting process, not the animation itself. 

I will try to explain myself again with an example. Let us imagine that the kid has
surrounded a pond (similar examples can be thought for tesellations, mathsticks,
gardens, etc) with some construction, and she has got an expression that she wants to
check.

The correct way to do this (according to what I have heard in the project for the
last month) is something like this. First, she "manifests" the expression (e.g. drags
it to the manifester box) and obtains a "manifester" with n charges, e.g. a
tile-dropper with 18 tiles to drop for a 4x3 pond. If the pond is changed, she can
manifest the expression again and the number of tiles changes (or not, if the
expression is not general enough). Then, the kid *herself* drops the tiles herself
around the pond; if the expression is correct, she will not run out of tiles, nor
will she have spare tiles at the end.

http://migen.wikidot.com/2008-05-07-task-meeting-notes

Automatic tiling (e.g. the kid manifests the expressions, and then some robot puts
the tiles automatically) is "magic", and thus not desirable for several reasons, as
you know. "

WRT #2: "I thought Darren was suggesting that a checker-manifester like gadget be
needed to generate a pattern (or at least color it in). The checker is something you
run AFTER building a pattern. This is a prerequiste part of BUILDING the pattern the
first time. Also the checker is a manual process, right? Quite different."

Maybe this is something I did not completely understand. It looks like we have the
same  idea about the manifester/checker (i.e to be used after building pattern, to be
used manually), and the issue is about something different. 

However, I do not fully understand what this is. Are you (DP,KK) proposing that kids
produce an expression even before creating patterns? Is that not the opposite of what
we have done up to know (using constructions to scaffold the development of expressions)?

(Additionally, is there a confusion here with the word 'pattern'? I am using
'pattern' as in eXpresser: an iterative repetition of a shape modifying its
attributes. But sometimes we use 'pattern' as equivalent to 'formula', or
'expression' (in the ShapeBuilder/eXpresser sense). I think there is no confusion in
this thread, but just in case).

Hi. I've cc-ed Manolis and Erini on this.

I was using pattern in the eXpresser sense but it was good to make sure.

I think the proposal is that kids produce expressions at the same time they create 
patterns.

Here's a concrete proposal. When you first reach the interface for defining a 
pattern (e.g. specifying the 'how many', the various increments, etc.) there is also 
a section (e.g. a tab) for specifying the 'rule' for the number of tiles that are to 
be used (of each color typically). One can fill this part out first if one is so 
inclined. If you don't fill it out then you see a ghost of your pattern (like a blue-
print).

Note the name of this issue. We are suggesting that the construction (specifying the 
pattern) and analysis (specifying the resources) be integrated. Both are needed to 
make a pattern appear.

Thank you for your proposal. I think an example has shed a lot of clarity over the
discussion. :-)

Your proposal makes sense, although I am not sure it is apropriate for MiGen. Why?
Because it looks to me like it will make the process more boring (and even
difficult). Think about the pond-tiling task from the learner's PoV: not only you
have to create the tiles, but you have to put an expression to make the tiles look
like alive (and not ghost); in other words, you have to make at least twice as much
work before constructing the solution. Think about the growing diamonds task: it is
even worse, as you have to think of cuadratic formulae even before you have finished
your construction; it looks to me like twice the work (read 'more boring task') and
increased difficulty. 

Is this really the way to go? Are we not trying to push formulae/expression too early
 into the tasks? 

Good points. Let me rephrase the proposal:

Build the eXpresser so that analysis can precede, be concurrent with, or follow 
construction. Leave it to the task designer to constrain the order as and if desired.

Sorry to come into this after so many comments. Lots of interesting points raised above.

Sergio> Just to re-iterate what Ken said: the point of what I said in Monday's
meeting is to *integrate* analysis with construction. As it stands at the moment, the
analysis phase (the manifester) is completely separate from the construction phase.
My worry is that children asked to 'build this pattern' will build the pattern, be
happy that it generalises and *then* be asked to build an expression. What is their
motivation here? They have already been general in their construction of the pattern
so I see the use of the manifester as a difficult stage to add on since I think
children won't be that engaged.

What I suggested yesterday is that the process of construction and analysis are one
and the same. We want to be able to see that when a child creates a backward C shape,
they realise they need 5 outer tiles for each inner one. By asking them to create
expressions for parts of their pattern piece-meal, we may have more of a window on
their understanding of the problem.

The idea that this will be even harder is not an issue to me. Without an appropriate
expression defining the amount of 'paint' (or whatever), the pattern shouldn't look
'quite right'. So, given the remit of 'build this pattern' by the teacher, they would
not have succeeded if they just generate the pattern itself without some
understanding of the number of tiles. They can still get the satisfaction of building
the pattern but it won't be submittable without the correct (or some attempt at)
expressions for defining the colours.

Even with this 'integrated analysis', the child can still opt to do the analysis at
the end if they so choose. They could do it at the beginning if they wanted too. This
gives the freedom of choice to the user (and is related to Ken's point above about
leaving this down to the task designer).

"What is their motivation here?"

There are several motivations:

1. The teacher tells you to do it (main motivation of 90% of school activities).
2. It is easier/faster/shorter to use language (an expression) to explain things to
your mates. 
3. The expression can be compared with other expressions, while the pattern cannot
(they all look the same once they are done). 
4. Maybe others...

"The idea that this will be even harder is not an issue to me." 

It is to me. If kids struggle to make patterns alone, putting another burden on them
will not be engaging, quite the contrary. 

However, maybe we can find a middle point. How about having this 'construction +
analysis at the same time' feature as optional? If the task designer wants the kids
to use the expressions as they build the patterns, ok; if she prefers that they do
not, then they just build (and colours are put in place for them, just like it is
now) and then build the expressions afterwards. 

Sorry I wasn't clearer in comment #7 but I think I was saying the same thing as 
Sergio's last paragraph.

Regarding the motivations listed:

1. Sad but true. I think we should strive for more than that.

2. I'm not sure an expression is an 'explanation'. It is a rule for making 
predictions about the number of elements of various types that will be needed.

3. If patterns are slowly drawn they can be compared much more easily than pre-
algebra students comparing two different but algebraically equivalent expressions.

4. The problem is intrinsically interesting. Maybe I'm an unrealistic romantic but 
math problems can have intrinistic interest. Isn't that what pure math is all about?