from Kathleen
They know the song, the leaf was on the twig and the twig was on the branch and the branch was on the tree . . . and one of the lessons I do with students is to take apart all the pieces that make a stop step go button so they see all the parts/objects and that the 'go' button still starts a script.
Believing that every thing is an object is a harder concept to understand than it appears. This might be because children take things as they find them and if it is an assembled thing they are disconcerted when they apparently break it. Thank you again for taking another look at the book problem.
from Scott
Still crying out for discussion is the general issue of "ease of disassembly". So here are some thoughts which hopefully will provoke such a discussion:
As you point out, many things can be happily disassembled and they'll continue to work, such as a "go" button within a stop-step-go complex. However, many other things may break, sometimes in subtle ways, when disassembled. It really depends on fine points of implementation detail. When a complex object is built up of layers of subparts, as a practical matter, it's unrealistic to expect that it will continue to function perfectly after being subjected to arbitrary disassembly. Some things will work, others won't.
This is not to say that your lesson in which you lead the kids through disassembly of a stop-step-go button and they realize that it is built up of many smaller subparts, and that things still work, is not a good idea – obviously it is. But because arbitrary disassembly does not always guarantee continued robustness, perhaps it would be prudent also to show the kids a cautionary example in which disassembly has unfortunate consequences. (With a little effort I could probably come up with an example or two of this sort.)
Anyway, about "ease of disassembly"... I can think of a couple of approaches here:
(1) We could put markers inside individual objects to indicate their reluctance to accept the halo – or, perhaps better, to indicate their eagerness to accept the halo. As you know, some of the objects in a complex hierarchy are "substantive" – they do real things – and others serve internal structural purposes but do not earn their keep as elements the user should be conscious of.
(2) Or, using a similar mechanism, individual objects could indicate their reluctance to offer the "destructive" halo handles when the halo is up (the pink "dismiss" and the black "pick up" handles are the destructive ones); the other, less destructive, halo handles would continue to be offered for such objects.
(3) In a further refinement, we could, for objects that are reluctant to offer the destructive handles, instead offer a different halo handle which serves to "unlock" the object, so that (temporarily) the full set of halo handles is shown for it. This would provide a "fence" to be hurdled, after which the user would be on her own, having proactively leapt the fence.
Another point of UI detail here, which many users are probably unaware of, is that if you hold down the shift key while doing a halo click, the innermost object is given the halo, and subsequent shift-halo-clicks move the halo out one level at a time. In this mode, every object in the hierarchy can obtain the halo, independent of other logic. This provides an escape which allows any object to get the halo, if the user is willing to try hard enough, even if the halo is otherwise unavailable because of some guard is in place.
from Tim
I like the idea of unlock, which matches the way things are in other environments like Flash, Fireworks, etc.
There's actually four concepts used:
1. layers
2. grouping
3. locking
4. embedding
Locking is usually about locking layers, so that you don't accidently pick something up you don't want to touch.
Grouping is about selecting multiple objects, then grouping them, so they behave in all respects like one object. You can always select & ungroup an object to see its pieces.
Embedding is more like what we're talking about ... you put an object within another object, and it behaves in the context of the parent (moves with it, etc).
I'd like to know what people think about these metaphors as they relate to Etoys ...
1) is there any use to a new metaphor?
2) can we get by with "lock/unlock embedded" menu item?
from milan
Scott, really like what you are describing above. It seems that implementing your item (1) would probably help most of the disassembly potential problems for users, and help creators put together rugged "assembled parts" from "parts", so I'll make a few comments on (1).
I like this very much. I cannot say how useful it is from educators perspective, but I watched my kids some years back having trouble with disassembling, and I had problems with it as well at the beginning.
A slight implementation alternative: I think of embedding as assembling the parts. Assembly can request that the halo not to be shown on it's parts (children), unless a child part requests otherwise. This way, by default, the "top part (assembly)" controls the halo of all it's children, rather than each child controlling it.
As each part should be able to also act as assembly, such control could be handled by combination of two properties: #refuseHaloOnChildParts(#refuseDisassembly?) and #overrideParentHaloRefusal(#canBePickedFromAssembly?). Let me think of an example: I want to build a Car. First I want to build Wheels from Tire, Rim and Bolts, and make them "assembled part", so I mark the wheel as #refuseHaloOnChildParts (so Tire, Rim, Bolts cannot be shown halo). Next, I build a Car from Body, Engine and I want to add the Wheels. Before adding each Wheel, I may choose to mark it as #overrideParentHaloRefusal. This way, when user starts invoking halo on the Body or Engine, it will not show, but halo on each Wheel will show (but not on Tire, Rim, Bolts).
To allow hallos on all the immediate child parts, user would have a menu item on Car #allowHaloOnChildParts. After selecting it, not only Wheel but also Body and Engine could be selected.
Re #3, Also the idea of a varying halo is interesting, sort of a context sensitive halo.
Scott, are you saying that no matter what "fencing" is implemented, the shift-clicking from inside should always show the hallo?
