LiveCode Forums

I have moved this discussion over here as there is the possibility to use pictures here,
while one cannot on the Use-List.

Personally I would do NOTHING in terms of restricting the capabilities of LiveCode.

I would consider (for Primary level kids) restricting access to capabilities via a curtailed revTools palette:

I'd either go for what I call the "short-arse" toolbar:
- -
Or a version of that with the addition of an image import button:
- -
I would also disable menu items that allowed access to other objects/controls.

Although this selection looks extremely mean indeed,for the first 2 weeks of an intensive 4-week course
(3 hours a day, 4 days a week) those were the only controls any of the pupils used.

I'd then expand the toolbar to include an oval and a rounded rectangle graphic
(for use with animations):
-

AND, I'd get all this out of the scriptEditor because it is just going to confuse the
diddly-doos out of the kids:
-

Seems to me what your describing has already been made by Richard Gaskin. His design even has a place holder for graduating a few new controls - I'm not sure how much more you could simplify the interface beyond that and have a useful toolset

As for the script editor additive handlers, it is one of the few things I find nicer in the newer IDE, since at a glance you can see a fair selection of handlers that (as a newbie) I didn't know existed. My guess is it would give anyone started a decent amount of learning jumpstart

As for the script editor additive handlers

Not for some 9 year old kid who is trying to get their head round the difference
between mouseDown and mouseUp.

To really get somewhere with anything that is going to work with the 9-12 year olds
one has to try teaching LiveCode to them.

Or, put another way: with EFL most teachers recognise the need to adhere to a heirarchy of difficulty:
you don't start using phrasal verbs with some kid who is learning how to write the colours.

https://www.jstor.org/stable/43135214?s ... b_contents

richmond62 wrote: ↑

Thu Oct 10, 2019 10:24 pm

Or, put another way: with EFL most teachers recognise the need to adhere to a heirarchy of difficulty:
you don't start using phrasal verbs with some kid who is learning how to write the colours.

Granted, but if they are just learning to write color names, they sure wouldn't be far enough along to tackle a programming environment.

Not being a teacher, I am making some very large assumptions in the above, namely -
if you are teaching them coding, they are past learning color names and ready to start learning phrasal verbs, otherwise the (probably) number one handler they will learn (mouseUp) will be no less difficult to grasp than to read from the sidebar.

*IF* that is the case, and it is a large if, then I still think it would give them a headstart and, at the very least, prevent a lot of frustration by making a typo in just the handler structure.

They also won't have to *guess* what to type into the dictionary to look up how to use specific handlers, like I did when starting out

Ah, yes; but "Mr Teacher" (Miss/Ms/Mz) might gently guide them
by telling them about mouseDown and mouseUp like I did by fooling
around with a mouse on the table and clicking the thing 'Down' and 'Up'
as children at that age are not capable of abstract thought.
- -
mouseStillUp

has already been made by Richard Gaskin.

I make no claims to originality in this respect.

I'm not sure how much more you could simplify the interface beyond that and have a useful toolset

Well, that statement can only be answered by a needs analysis.

I once cooked a pizza, right from flour and water up, with a plastic bag, a knife and a sheet of metal (old computer side panel)
on a fire on a beach. But, given the choice, a mixing bowl, a board to roll out the dough and so on would have made things
considerably easier.

As soon as we start working on the basis of a needs analysis we end up in subjectivity land
where Richard Gaskin's Devolution (or something like it) comes into its own.

Different teachers with different groups of pupil will need different toolsets . . .

I suppose, in a perfect world, I'd want a toolset that slowly "unfurled" as a course progressed.

Ah, well therein lies the rub, if you desire a slow unfurling, I'd start with what Richard has, and implement a function to change the custom buttons over time to match the course speed. Of course, that wouldn't be very flexible.

Another option would again be to start with Devolution as it sits, then teach the students at some point to create each new control as it is needed, which is far more flexible but might lead the course off of a fixed routine. On the plus side, though, it would add learning how to do some customization to the environment your working in.

What I did in my Coffee Break
- -
Of course this presupposes you have hidden all the other sections of the toolbar already.

I've deleted the stack as there is an improved version further down this list.

That is pretty slick, now all you need to do is add the 'move each of the shown buttons into a grid format' command and resize the palette to match the size of the displayed grid

*Edit -
Also, ah 'ooops'...

No "ooops" round these parts: at my school;

LiveCode 8.1.8, MacOS 10.7.5

I wonder what this button is now called in 9.0.5/9.50:
- -
and what possible advantage could have accrued from renaming it.

now all you need to do

Indeed: I love you too.