-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for robot interaction within block editor #119
Comments
To correctly understand you I think you mean the advantage of 1 " the robot could potentially still run" |
I made a mistake in my phrasing (now corrected), I meant that the advantage of 1 is that the robot could potentially still run. In general I am very careful with publicly-available options, as they typically show that we did not find a good default behaviour, they confuse most users, and they require more implementation, maintenance and documentation work. I think that one of the reason macOS is so successful with teachers who can afford it is that it provides simple ways of doing basic things, that users can learn and feel safe with. Options are spooky for most users. Actually, macOS has tons of options that can be enabled only with the command line. This allows the power users to still customize the system why not requiring a proper user interface and documentation for these features. |
The default behavior should propose the option with the robot interaction enable. I understand your point of view to not scary the teacher with options, but a teachers could like to disable sound editing in a classroom. Also I am still not convinced about stopping the robot when you edit a program so it could be an option of having still your code working, or having your robot stop and have "coding interaction". Another issue: |
If we do not do so, the feedback makes no sense. We could disable it in that case. Based on my previous observations, I think that stopping the robot is the best thing to do, in particular because most users want to keep track of what is going on, and a single thing should be going on in the same time to make this tracking easy, but we should do more tests with users.
This is an interesting option, and should be in its own issue. Currently the volume is controlled on the robot. Do you think it would make a huge improvement to control it from VPL? We could imagine a volume control icon that appears when the robot is connected. |
Since I am not enough aware of what this implies in term of developpement I will let you decide about this. My comments :
For the volume I think this is great but it opens more questions :-) Do we think about calibration and other "options" too ? |
Yes these are meaningful questions, and indeed we should open issues for them. |
It would be useful to have the possibility for VPL to interact with the robot (if connected) during block edition. For instance, as suggested by @Vincebecker, sound preview could improve the music block. The same applies for the colour block, and for distance and ground sensors blocks to see the actual values of the sensors, especially in an advanced mode where thresholds can be set manually.
There are different ways to implement that:
The advantage of 1 is that the robot could potentially still run, or at least, easily be paused and then continued. However, currently modifying a program stops its execution, so this is not a strong requirement. Moreover, this has a cost in term of the size of the generated program, which I think we do not want to pay. So I vote for 2.
The text was updated successfully, but these errors were encountered: