Provide a Thymio launcher

[stephanemagnenat]

We wish to provide a Thymio launcher dialogue box. This box should provide access to:

• Studio with a default connection to local Thymio (serial or simulated), or if none or multiple available a Thymio-only result of discovery.
• Thymio VPL standalone with a similar connection option.
• Blockly and Scratch (through webbridge, hidden from the end user).
• Thymio wireless configurator.
• Thymio firmware upgrader.

Also, it would be helpful to have access to the following elements:

• Web site or documentation.
• Email registration.
• Credits and partnerships.

There are several design questions to address:

1. The first key question is whether this launcher should show a list of robots first (as in the example of Christophe in Provide Thymio-specific connection dialogue #694), or a list of tools first (as currently in the system start menus).
2. How to visually split the main programs (Studio, VPL, Blockly, Scratch) and the tools (wireless configurator, upgrader).
3. Whether this launcher should check if a serial-connected Thymio requires upgrade.
4. Whether the launcher should check Aseba version and provide information to the user, and later automatic Aseba upgrade.

[davidjsherman]

We should try to provide the least number of clicks. So I would suggest either a matrix of targets by actions, or alternatively a list of targets with action buttons.

Thymio-II 1     [Studio] [VPL] [wireless] [firmware]
Thymio-II 534   [Studio] [VPL] [wireless] [firmware]
Playground 2    [Studio] [VPL]
Dummy 0         [Studio] [VPL]
Switch 1234     [Studio] [VPL]

[FrancescoMondada]

I agree with the matrix of @davidjsherman but if we establish the matrix based on a list of discovered target, this would require to start the simulator first, adding a step. We should put in the matrix both the discovered targets and the possible activable targets (simulator).

[stephanemagnenat]

Yes. We can have a smart dialogue box that shows the activable target only if no Playground with Thymio has been detected. Although it is not sure that this is a good idea, as users might want to connect to another simulator.

I think that we should collect experience from users who use Playground to see their typical use case, and make this one easy.

[davidjsherman]

Thymio-II 1         [Studio] [VPL] [wireless] [firmware]
(+) New Playground  [Studio] [VPL]

If the launcher starts the Playground as a QProcess, it can wait for the Playground to start up, then start Studio or VPL on the lowest-numbered target. (In the UniFr playground, the lowest-numbered target is a switch.) Other students will see the remaining targets in their launcher, advertised by Zeroconf.

I suppose one could make “New Playground” active, if there were a use case for starting a playground without automatically connecting to one of its targets. In that case the targets will appear in the launcher, like “Playground 2” on line 3 of my comment above.

[cor3ntin]

A few ideas that got tossed around :

• Check for software updates ( check only , invite the user to visit the website )
• Check firmware updates for Thymio connected via usb - only offer to update the firmware when relevant
• Monitor the web-bridge through a taskbar icon ( instead of having a cmd prompt or invisible process)
• The UI could be sorted by frequency of use

It's unclear to me whether it would be better to choose an activity and then a target or the other way around.
While a matrix layout has the advantage of being on-click, it may also be more confusing.

In any case, I think it's reasonable to have a "Default" and "advance" mode for non-thymio targets, etc

[davidjsherman]

I say Keep It Simple. It's a launcher, not ESOC Darmstadt, and our core users will be ten-year olds.

Updates are rare events, it seems to me that cluttering the launch page with that has a low ROI. And the core users of the launcher wouldn't be performing software updates themselves, anyway, would they?

The web bridge shouldn't need to be monitored. If it's not working, it should be healed automatically.

What's a task bar icon?

[cor3ntin]

I say Keep It Simple. It's a launcher, not ESOC Darmstadt, and our core users will be ten-year olds.
Agreed.
At the same time, teachers have different needs than students and we should probably accommodate both use cases.

Updates are rare events, it seems to me that cluttering the launch page with that has a low ROI. And the core users of the launcher wouldn't be performing software updates themselves, anyway, would they?

You only get notified if there actually is an update. I agree that only teachers need to know about that.

What's a task bar icon?

Basically a small icon whose presence would let you know that the web server is running.
It could let you configure whether closing the browser (blocky/scratchpad) shutdowns the server.
I think you made an issue about that somewhere.

[davidjsherman]

These are good ideas. Maybe this would be a good use of the "professor mode" icon from VPL?

[mbonani]

I put here some old brainstorming we add:

• on of the element was to distinguish what is "supported" and what cames from the community
• can be also what is on "development" what is "stable"
• it was also to better show who contribute in what.
  here a very quick mockup:

now the discussion with first discover the target change the mindset. Even I don't think firmware updates or wireless configuration are be shown in the matrix. Basically what we can do with a real Thymio can be done in the simulated one. People want to programm it, they want to easy find the program they want (VPL, studio, blockly, scratch).
To find the firmware updater or the network simulator should be also possible but it is not the main usage of the robot, this are tools.

[cor3ntin]

With kids in mind, I'd say a 2 clicks/ 2 screens approach seems simpler, less cluttered than a matrix approach.

1/ Choose the software activity
2/ Choose the device/target to do do that activity.

2 is filtered to only show devices compatible with 1.

I think we can always show community software, no need for a checkbox.
However, we can put them under a separate category, and when you click on them, you get a pop up telling you they are not supported, with a "don't show again checkbox", or similar mecanism

At the same time, you have a "settings" icon from which you can access configuration & update, some kind of "Update Available" icon, conditionally displayed, and a toogle basic/advanced mode

[stephanemagnenat]

Regarding the mockup, I think that there is too much text and it is too cluttered. Rather, we should only show icons with maybe one small text below (eg. "Text programming (Studio)", "Visual programming", "Blockly programming", "Scratch programming", "Configure wireless Thymio", "Upgrade Thymio firmware").

Regarding community, I think that there are too separate concepts to express: programs that are experimental, such as Scratch or Blockly, and programs that are part of the community. For now there are none in that category.

[mbonani]

Putting the mockup was a bad idea, it unfocus the discussion.
Blockly4Thymio, is for me in that category

[stephanemagnenat]

I really advise against advertising Blockly4Thymio in the Thymio launcher, as it would create confusion for our users with the Blockly we provide, and it does not provide the integrated experience Aseba-based tools typically provides. In particular the way Blockly4Thymio is architectured (generate an AESL file and call massloader) is ad hoc. Moreover, as far as I have seen (but maybe I missed it), Blockly4Thymio is not open source.

[cor3ntin]

We had a meeting with @mbonani and @Vincebecker.

We came up with the following conclusions

• To avoid confusion, responsibilities issues and support burden for Mobsya, the launcher will not include community-provided softwares.

• We want to add communities features like account, email-registration or news feed. However, there are concerns regarding how this features would be used in school rooms and by young children. We need to run a survey by teachers to better understand their needs. There are also legal implications.

• The first launcher version won't have community feature but a link to the website, as well as an about/credit window.

• We think it would be better to first choose the application, then the target.

• Each application would have a small description visible on rollover. either as a tooltip or frame in the application.

• Once you choose an application, you get prompted with a list of compatible connected thymios, physical or simulated.

• You can also start a simple playground from there and the list would get updated as thymios get connected.

• Thymio are represented by user-friendly names and icons, the notion of target / target path is abstracted away.

• We want to make the selected thymio emit a sound

• We want each thymio to have a configurable name, such that teachers can put a label on each thymio

• In a future iteration, we propose to offer a more user friendly way to start a playground by displaying a list of maps. not for 1.7 though

• We might add more features in the launcher latter but the initial goal is to make the simple case simple. Launch aseba directly if you want to connect to an non-thymio device.

• When launching blockly, asebahttp will be launched behind the scenes and provide a status icon.

• We will detect firmware and software updates. We won't actually do the software update automatically, for now.

@Vincebecker will be doing some mockups and assets, but we are going to wait for feedback before going ahead with implementation.

I hope I didn't forget anything.

[stephanemagnenat]

In general this is good. Some remarks:

We think it would be better to first choose the application, then the target.

Do you plan to add a Thymio-specific target selection in the launcher? Aseba programs such as Studio and VPL can take a target as command-line argument. Be aware though that a Dashel target and a robot are different, and so if there are multiple Thymios in a target, currently VPL standalone reports an error for example. It is a question whether we want to support Dashel targets with multiple Thymios. I strongly suggest to answer no, at least for the first version.

We want to make the selected thymio emit a sound

We would need to discuss whether and if so how this affect Aseba protocol. Of course without modifying the protocol we could compile a small program that receives an event and emits a sound.

I suggest not to implement that feature in a first version.

We want each thymio to have a configurable name, such that teachers can put a label on each thymio

If this is in Wi-Fi Thymios only it is relatively easy, as @davidjsherman pointed out there is the Zeroconf name for that. If we want that to go through switches it would require more discussion. Again, I advise to go for the simple case first, to avoid over-engineering.

We might add more features in the launcher latter but the initial goal is to make the simple case simple. Launch aseba directly if you want to connect to an non-thymio device.

Yes, this is important.

We will detect firmware and software updates. We won't actually do the software update automatically, for now.

I guess only for physically-connected Thymios, right?

[cor3ntin]

Do you plan to add a Thymio-specific target selection in the launcher? Aseba programs such as Studio and VPL can take a target as command-line argument. Be aware though that a Dashel target and a robot are different, and so if there are multiple Thymios in a target, currently VPL standalone reports an error for example. It is a question whether we want to support Dashel targets with multiple Thymios. I strongly suggest to answer no, at least for the first version.

Agreed, not for 1.7

We would need to discuss whether and if so how this affect Aseba protocol. Of course without modifying the protocol we could compile a small program that receives an event and emits a sound.

Compiling a program seems the proper solution.

If this is in Wi-Fi Thymios only it is relatively easy, as @davidjsherman pointed out there is the Zeroconf name for that. If we want that to go through switches it would require more discussion. Again, I advise to go for the simple case first, to avoid over-engineering.

It's complementary as zeroconf would report the set name by default. I haven't looked how pid are reported, but it would work similarly.

I guess only for physically-connected Thymios, right?

Exactly.

[stephanemagnenat]

It's complementary as zeroconf would report the set name by default. I haven't looked how pid are reported, but it would work similarly.

There is already a support for a node having a name, so it could be used as ProductId would report Thymio. See common/msg/TargetDescription.h:77.

[cor3ntin]

Some technical ideas and questions, so I don't forget about them

• There should not me more than one running instance of the launcher ( at leash, for a given installation path )
• Should we handle a asebahttp with more than one thymio connected by usb ? In which case we need a way to dinamically add more targets.
• Do we need a separate web bridge at all ? The launcher could act as a webridge.
• Can there be more than one instance of any client for the same device ?
• Should the launcher support non-default tcp ports ?
• Each client could be represented as a json/xml/ file describing an application name, a description, a command line or url, icon, tags ( for filtering purposes ), version.
• Command line would contains something like ${targetName} which would be replaced by a dashel target after device selection.

[stephanemagnenat]

Should we handle a asebahttp with more than one thymio connected by usb ? In which case we need a way to dinamically add more targets.

asebahttp is an unmaintained temporary hack, David Sherman and I have been working on a clean new switch, in the branch http-refactor. We should talk about it after the 1.6 release.

Do we need a separate web bridge at all ? The launcher could act as a webridge.

It is a very interesting idea. The new switch is very modular and in that sense could be used within the launcher. I think we still need a standalone asebaswitch, but of course both could co-exist.

Can there be more than one instance of any client for the same device ?

No, the Aseba protocol does not support that at all. At most one IDE/client can be talking to a node at any given time. This is not enforced in any way but if this assumption is violated, the behaviour is weird on the client side. That is why all simulated targets stop advertising themselves as soon as there is an incoming connection. I think that a Wi-Fi Thymio should do no the same, and probably that a clean web bridge as well.

Should the launcher support non-default tcp ports ?

Do you mean for connecting to targets? I would say that for advertised ones yes, otherwise no.

Each client could be represented as a json/xml/ file describing an application name, a description, a command line or url, icon, tags ( for filtering purposes ), version.

Yes but I think it is over-engineering, a proper const array of structure created through an initializer_list in C++ seems fine to me.

Command line would contains something like ${targetName} which would be replaced by a dashel target after device selection.

Yes, correct.

[cor3ntin]

We should talk about it after the 1.6 release.

I know... Hopefully we will be able to get that out of the way soon !

It is a very interesting idea. The new switch is very modular and in that sense could be used within the launcher. I think we still need a standalone asebaswitch, but of course both could co-exist.

That was my idea, link to a shared library and have both a cli and the launcher.

No, the Aseba protocol does not support that at all. At most one IDE/client can be talking to a node at any given time. This is not enforced in any way but if this assumption is violated, the behaviour is weird on the client side. That is why all simulated targets stop advertising themselves as soon as there is an incoming connection. I think that a Wi-Fi Thymio should do no the same, and probably that a clean web bridge as well.

I'm not sure that's the most user friendly approach. We should mark the target "busy". And hopefully, if there is already a client (aseba) running, we can notify it and prevent multiple instances to ever occuring

I think someone not familiar with aseba would not understand why devices disappear.

[stephanemagnenat]

I'm not sure that's the most user friendly approach. We should mark the target "busy".

Indeed, David Sherman and I planned that, but moved to 1.7 because of timing constraints, see #690 and #713.

[cor3ntin]

Yeah, I know. I was pointing out that the launcher should use that feature when it's done !

[Vincebecker]

Hello,

Here are the first mockups based on the discussion with @cor3ntin and @mbonani and your comments.

Interface - Select how you want to program :

When you push the "tools" button (list is not complete)

When VPL is selected, select the robot or simulated robot or click (+) to launch a basic simulator with one robot and connect to it. click launch. screenshots are here to give a preview of the language, we can replace it and use this space later (access to a database of programs, activities, video tutorial of the selected language, invitation to update, .... (only suggestions))

So, 3 simple steps,

1. select software 2) select robot / simulated robot 3) launch

Advanced users can launch a simulator from the tools menu and the simulated robots will appear in the list as "simulated device".

[davidjsherman]

Are we licensed to use the Scratch logo?

[stephanemagnenat]

Thank you @Vincebecker for the mock-ups. I find the overall concept excellent!

I have some minor questions and issues I see with the current version:

• Please check that it works in low-resolution screens. Especially in schools, sometimes the resolution is really low. Originally Aseba was designed to work with screen with resolutions as low as 640x480, probably today 800x600 is a reasonable minimum, but it might be worth checking.
• Is the download icons on the top-right corner for updates?
• Is the info icon showing a standard about box? How is that related to the credits on the bottom of the screen?
• In the third mockup image, there is a nice screenshot beside the icon, how would it look for an icon that is not on a side, such as Thymio Blockly?

[Vincebecker]

Thanks to both of you for your feedback.

@davidjsherman for now it's only a mockup. I will ask right now and if it's not possible we will create an icon.

@stephanemagnenat

1. sure we will make sure it works with lower resolutions.

2. Yes it's for the updates. Maybe something like this is better :
   

3. If I understand well : the blockly icon will slide to replace the vpl icon so the user always know what he selected.

[Vincebecker]

@stephanemagnenat

Is the info icon showing a standard about box? How is that related to the credits on the bottom of the screen?

Yes, maybe the bottom of the screen informations will be only used for version information. Let's think about this tomorrow.

[stephanemagnenat]

@Vincebecker

1. good
2. I like the preview one, just wanted to be sure
3. ok, I am unsure if this behaviour is natural, but it is easy to prototype with QML

[Vincebecker]

Following our discussion I am wondering,
We said that, we want to add a simulator map selection screen when the programming language is selected (third mockup image).

I fear that it will add complexity for the user to have map selection / robot selection in the same windows.I mean the user will not understand why we propose to chose a map if his robot is connected.

Solution 1 :

Do we add a step ?

Step 1

Title / Screenshots / Description / Author of the language (?)
ask if the user wants to use a robot or a simulator

Step 2

if simulator
Screenshot (changes when a map is selected ) / description about the map selected / Author
Select a map / select a simulated thymio /
launch button

if robot : 1) select robot 2) launch

Solution 2 :

Do we detect if a Thymio robot is connected and don't show the simulator options ?

Personnaly I prefer solution 1, it shows all the available option and guide the user.

What do you think ?

[stephanemagnenat]

I think that we should add a step, if the user clicks to launch a simulator (instead of connecting to a robot), she is provided with a map selection dialogue. If a simulator is already running, she is asked whether the map should be replaced. So I suggest the following user interaction with the launcher:

1. select program
2. select robot/target
3. if target is unlaunched simulator, select a map (this might even be a new modal dialogue box), and then launch the simulator with this map.

[cor3ntin]

I agree with stephane.
Always display a "simulated thymio" icon, if no simulated thymio is present, offers to create a map.

[Vincebecker]

I agree too.
This mockup follows the idea of @stephanemagnenat and

Here is when you select "Simulated Thymio" (note : map selection is not visible if you don't select "Simulated Thymio")

Then when you select the map, the left pannel changes to give more information, also you can change the map and the new simulated devices will appear (or do we keep it simple for the launcher?). If you click on a real Thymio you switch back to Mockup 1.

[Vincebecker]

With @mbonani and @cor3ntin , we discussed about how the users could use the launcher. Here is an update of the mockup.

[stephanemagnenat]

In general it looks nice. I have some comments:

• What about having a left "<" back button as in mobile devices instead of the right arrow to go back to the previous screen? That seems more natural to me.
• When selecting the simulator, in theory you could imagine to have the selected robot to blink in the preview screen, if the latter is actually a small running playground, which is totally doable with some work.
• When selecting a physical robot, it should somehow indicates it is selected. This is not trivial and has already been a bit discussed in Aseba Studio and VPL: focus on only one node #558 and orally in the past. I think we should keep that question outside this issue, but I wanted to mention it for the sake of information flow.

[Vincebecker]

What about having a left "<" back button

Because the animation that open this pannel is a "bottom-to-top" animation so, to close it, you send it back to the bottom. If we change the animation to left-to-right, yes, "<" is better but since the pannel is wider than high I think bottom-to-top is better. Sorry I did not mention the animations, I think the best is to try a few and then decide what we prefer. That will define the final signaletic.

When selecting the simulator, in theory you could imagine to have the selected robot to blink in the preview screen, if the latter is actually a small running playground, which is totally doable with some work.

Amazing ! Is it possible to focus on the selected robot (like a moving camera) ? Or do we have to show the entire playground in the preview image ?

When selecting a physical robot, it should somehow indicates it is selected.
you mean like making the robot blink when you select it on the launcher ? Yes, If think this is very useful !

Also, @davidjsherman I just go the information, We can use the Scratch logo.

Thanks everyone for your feedback.

[stephanemagnenat]

I agree about the animation, considering one bottom-to-top, we could have a "V" button somewhere.

Amazing ! Is it possible to focus on the selected robot (like a moving camera) ? Or do we have to show the entire playground in the preview image ?

In principle yes. Note that, as I said, this is possible only with further development, so we should not expect this in the first version of the launcher. But we can keep in mind that it is theoretically possible and deploy that in a further release.

[stephanemagnenat]

Showing an interactive simulator depends on enki-community/enki#51. Based on a rough look at it, it should be possible to do with some work.