VPL alarm timer - should it be "stepped"? (like the motor control)

[ddoak]

It is hard to accurately (or reproducibly) set the alarm timer in VPL. The range of the variable is large compared to the precision which can be achieved by dragging.

I've found this particularly frustrating when trying to experiment with state based shape drawing in VPL where it would be useful to make systematic adjustments to durations - or to be able to set an equal duration for different timers.

In contrast, setting the motor speed control is stepped / quantised in units of 50.

Was it a deliberate design decision to have the timer setting continuous?

Would it be better if it was quantised to 50ms increments?

[stephanemagnenat]

I agree, it would be nice.

[motib]

This is important! The unreliability of setting the timer is annoying. However, I think that 50 ms is over-optimistic. I even have problems using the mouse to set the motors to one of the 10 steps of their range. 50ms over 4 seconds would give 80 steps, far beyond my ability to control the mouse. In my opinion, intervals of 1/2 or at best 1/4 seconds would be sufficient.

[stephanemagnenat]

An argument against having too large steps is to be able to control precisely enough something like a quarter turn, a half turn, etc.

[stephanemagnenat]

Implemented in commit af5239a693846060953591faf31db3a61d09ef07, with 100 ms resolution as initial value for testing.

[stephanemagnenat]

If you are happy with the implemented version, please close the issue.

[ddoak]

As implemented the quantisation certainly works. However I think @motib has a valid point about compromises for usability.

I was hoping to test the usability with a bigger "handle" (as suggested in #348) before closing.

[motib]

I like the quantization but I think that 100ms is too fine to control and the interval is too short to be meaningful in this context. I suggest 250ms.

[stephanemagnenat]

I agree with you in principle, but as the timer is quite useful to control the movement of the robot, I am reluctant to setting a too coarse quantization. But we can discuss :-)

[motib]

This is VPL ... so I ask: Is there a reasonable task for novices that requires fine quantization? I would be interested to hear if you have something in mind! Personally, I can't think of one that requires less than 1/4 or even 1/2 second. Any really delicate task that requires such fine control would probably be done in AESL where there is full control over the timer duration.

[stephanemagnenat]

I could imagine that the novices would play with the timer to have the robot doing a half turn, when playing with states.

[ddoak]

I intend to write up an example for the wiki which I think is a good test / illustration of this.

The example will be an exploration of periodic geometric drawing using advanced VPL (timers, state setting to control motors - basically an extension of https://aseba.wikidot.com/en:thymiodrawing - but using only VPL). I think this has the potential to be a good bridging activity.

With repeated (motor) events (for drawing) it is very interesting to explore the effect of small changes in timers - and so 100ms increments would be useful.

That said, it is definitely tricky to precisely manipulate the timer handle with the 100ms quantization and in my experience children find it particularly difficult to execute accurate drags with trackpads.

A possible compromise would be to quantize at 500ms in basic VPL and then go to 100ms in advanced VPL. The difference could perhaps be indicated visually by extra ticks on the clock face.

Just thinking out loud - I'm wary of adding extra coding work!

[stephanemagnenat]

I somewhat like the idea of changing the quantization factor depending on the mode. @motib do you like that idea?

[motib]

I performed an experiment this morning: running a line-following VPL program (at 400 motor power), stopping the Thymio by setting a timer, and measuring the distance. Setting the timer action block to 100ms increments was quite a challenge :-((. Furthermore, the difference (about 1cm) in the measurements for 2.0 vs. 2.1 seconds was about the same as the jitter when running the same duration multiple times. So I'm totally against a 100ms increment.

A duration of 2.2 seconds gave consistently different measurements (about 2cm) when compared with 2.0 seconds, but that's not much more than the jitter.

My suggestion is still to use 250ms (or, if you insist, 200ms) increments.

Concerning the dual-mode timers: I thought that we liked the idea of moving the timers to advanced mode :-). I wouldn't bring them back to basic mode, certainly not just to resolve this relatively minor issue. In addition, this would be a case where advanced mode is changing the semantics of a block, not just adding new features and this may cause confusion.

[stephanemagnenat]

Hi Moti, Thanks for the experiment, it is good to do evidence-based user-interface design :-) Francesco is super against having the timer in the advanced mode, he says that he likes using it when teaching teachers relatively early, and I might put it back to the basic mode for that reason. But the underlying issue for me is that the timer like it is now is probably not the good way to create programs with temporal effects. I believe that it would be better to link pairs together through delays to build co-routines. Also, if possible at some point I would like to explore the Kodu-way to do states: by having different panes for different states. But all that is future work. For VPL 1.4, I would agree to try 250 ms.

[motib]

I'm not "super against" having timers in basic mode, just "very mildly against", so I'll defer on this!

[ddoak]

I think 250ms is a sensible compromise to explore usability with. I'll have a play and see what flexibility that gives for exploring pattern drawing (and, of course, varying motor speed can also be used in conjunction with the timer to achieve finer control).

If you look back to my opening comment on this issue - the major problem then was the frustrating inability to reproducibly and accurately set the timer - this is certainly fixed.

Incremental precision is a slightly different issue - but perhaps if the user has got to the stage where they are thinking that they want to precisely tweak timer values then it is time for them to move on from VPL.

@stephanemagnenat should I now close this issue for 1.4?

[stephanemagnenat]

@ddoak yes, let's close this issue. And if while testing problems appear, we can always re-open it!