One of Arduino’s main tasks in Decode is to create an open hardware design for a secure internet gateway (also known as “hub”) that could enable people to have local control of their data. However, this blog post is not about the hardware design - something that we will be covering in a later post - but about the possibility of having a visual programming environment (VPL for short) that could be used to allow users to re-configure a device like the DECODE hub.
This would mean that someone taking part in a DECODE pilot would have the freedom to configure his / her DECODE hub though a visual interface so that it reflects how they want to use the tools. This could be changing the way data is displayed, enabling external services accessing the data, or remotely operating parts of their DECODE enhanced environment.
One of Arduino’s goals is evaluating different ways of programming microcontrollers at a conceptual level. One recent internal study analysed what is important when talking about visual programming languages, and what should be taken into account when designing a VPL that can be used to program any kind of hardware.
There are a number of metaphors that can be used to think about VPLs:
-
CODE: this metaphor underpins all others. Most of the time we see systems that end up generating code. Unless you are in front of a VPL that uses some sort of static firmware on your Arduino board, the VPL will translate whatever visual representation of the program you have on the screen into a piece of code to be compiled and uploaded to the board
-
BLOCKS: thanks to the efforts made by MIT in the creation of Scratch, or Google’s Blockly, we see this as the most used VPL metaphor for the time being. This metaphor involves letting the users manipulate a series of graphical elements (blocks) that snap onto one another and that execute sequential programs, like for example controlling the way the heating or a fan will react to the data provided by a temperature sensor
-
FLOW: at Arduino we have presented one of the few FLOW programming environments ever made for Arduino boards through the EU-funded project PELARS. We call it the ESLOV programming environment and it consists of physical electronic modules that can send and receive data both to one another and to a GUI (Graphical User Interface). They operate according to the graphic topology established on the screen
-
CARDS: this is the now classic IFTTT -type interface. It is as if users had two decks of cards: events and actions. Programming happens by putting together an event card and an action card. In that way, when a certain event happens, the microcontroller will perform the action listed by the card. The different events can happen in parallel
Currently, when looking at designing a hub for the DECODE project, it is clear that the CODE programming paradigm should always be there. Expert users are willing to use such an interface in order to make the best out of their systems. On the other hand, when approaching the average user, it will be more convenient thinking about either using the CARDS or the BLOCKS metaphors, as they represent two ways of thinking about how to program devices: sequentially or in an event-based fashion. The FLOW metaphor, which is used e.g. in the NodeRed open source project, happens to be very powerful, but also complex to use for novice users.
DECODE's technical team will be considering the VPL over the next few months, taking into account the needs of both expert and everyday users in the DECODE pilots. If you have any thoughts on this, we'd be really keen to hear from you. Our email is info@decodeproject.eu or you could contact us on @decodeproject on Twitter
DECODE was funded by the European Union's Horizon 2020 Programme, under grant agreement number 732546.