=Paper=
{{Paper
|id=Vol-2934/paper2
|storemode=property
|title=Physical or On the Cloud: Play with IoTgo and Design Smart Things
|pdfUrl=https://ceur-ws.org/Vol-2934/paper2.pdf
|volume=Vol-2934
|authors=Rosella Gennari,Alessandra Melonio,Mehdi Rizvi,Maristella Matera
}}
==Physical or On the Cloud: Play with IoTgo and Design Smart Things==
https://ceur-ws.org/Vol-2934/paper2.pdf
Physical or On the Cloud: Play with IoTgo and Design Smart Things
ROSELLA GENNARI and ALESSANDRA MELONIO, Faculty of Computer Science, Free University of Bozen-
Bolzano, Italy
MEHDI RIZVI and MARISTELLA MATERA, DEIB, Politecnico di Milano, Italy
Smart things, such as smart watches, are popular. Designing them requires technical skills and critical reflections in design, e.g.,
concerning safety risks due to their physical nature or data they exchange. Engaging end-users in design and reflections is thus
complicated and yet beneficial, e.g., to make them aware of such risks. Play can help engage different end users, and especially teens.
This paper reports on the latest evolution of the IoTgo playful toolkit for engaging different end users, and especially teens, in design
and critical reflections. It presents a case-study across a pandemic with IoTgo used by teens and adults.
CCS Concepts: • Computer systems organization → Embedded systems; Redundancy; Robotics; • Networks → Network relia-
bility.
Additional Key Words and Phrases: Smart thing, IoT, Physical computing, Cloud computing, Teen, Action research
1 INTRODUCTION
1.1 Context
People nowadays, and teens especially are surrounded by smart things, such as watches or street lamps, capable of
processing data and interacting with them accordingly. Data are exchanged through physical devices attached to things,
i.e., sensors and actuators. Devices and data are distinguished into input and output ones. Examples are a distance
sensor as input for distance data, and an LED matrix for light effects as output. A micro-controller or another similar
computing device can be embedded in a physical thing, such as a lamp, and make it “smart” with a program. In the case
of a street lamp, the program can use the distance sensor to detect whether there is something close to the lamp and, in
case so, the LED matrix lights up in bright colours.
Other data are related to cloud-computing services, e.g., environment data or Twitter posts. Data are thus exchanged
on demand with services available on the cloud. Again, services and data can be input or output ones. In case of a street
lamp, input data can pertain to rain forecasts for the area where the lamp is positioned, fetched from a weather forecast
service, and they can be used to program the lamp to switch on in case of heavy rain. Output data can be related to
Twitter posts, which can be sent in case of heavy rain. This requires the lamp to embed a computing device capable of
exchanging data with cloud services, via dedicated communication protocols.
Joint workshop on Games-Human Interaction (GHItaly21) and Multi-party Interaction in eXtended Reality (MIXR21), July 12, 2021, Bolzano, Italy
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Authors’ addresses: Rosella Gennari, gennari@inf.unibz.it; Alessandra Melonio, alessandra.melonio@unibz.it, Faculty of Computer Science, Free University
of Bozen-Bolzano, Piazza Domenicani 3, Bolzano, Italy, 39100; Mehdi Rizvi, syedmehdi.rizvi@polimi.it; Maristella Matera, maristella.matera@polimi.it,
DEIB, Politecnico di Milano, via Ponzio, 34/5, Milan, Italy, 20133.
1
2 Gennari et al.
1.2 Motivations
The design of such smart things, which are technologically complex, requires technical knowledge concerning physical
computing as well as cloud computing, and thus to consider physical aspects as well as less-tangible aspects. However,
it also requires responsible design, given that smart things have an impact on society. There is a significant debate in
research concerning responsible design, considering responsibility by design, for design and in design [5].
Responsibility for design means having accounting mechanisms for ensuring that risks of socio-technical systems
are properly managed. Responsibility by design focuses on responsibility in the usage of existing technology. Instead,
considering responsibility in design means ensuring that design is reflective and takes into account different implications
of design choices, primarily on society. This paper takes the last perspective, and it considers how to frame smart thing
design so as to conduct reflections in design.
The debate on design with reflections along the process tends to address specialists, such as experts of smart things
or ethics, e.g., [14]. However, engaging end users in design and reflections in design is potentially beneficial. Engaging
end users across the design of smart things can help end users understand how design works, and critically reflect
on their impact on society. However, bringing design to end users is by no means an easy task, especially with teens.
Although younger generations tend to use smart things frequently and to feel confident with them, they do not often
know the inner working of a smart thing, and hence they may not be able, on their own, to reflect on their choices and
their implications, critically [9, 13].
1.3 Focus
This paper presents the IoTgo toolkit, which aims at playfully guiding end users of smart things, and especially teens,
through smart thing design and reflections in design. IoTgo is card-based: it has decks of game cards and game boards,
where cards are played, for ideating and reflecting. It also comprises ad-hoc developed tools, based on micro:bit and
Raspberry Pi boards, for translating ideas from game boards into working prototypes [11].
This paper explains the rationale of IoTgo and how it evolved through actions with teens, mainly, conducted over
time with an action-research approach, as in the work by Gennari et al. [8]. In particular, the COVID-19 pandemic
affected its evolution. From a toolkit for in-presence design and reflections “around a table”, IoTgo became a portable
playful toolkit catering for individual and collaborative design, besides stimulating reflections at a distance. The paper
reports on a case study with the latest evolution of the toolkit, adapted to the pandemic.
1.4 Outline
The paper is organised as follows. Section 2 outlines work related to card-based toolkits for smart-thing design with end
users. Section 3 sketches the evolution of IoTgo over time, and across a pandemic, and it describes the latest incarnation
of IoTgo. Section 4 reports on the latest case study with two teens and two adults, playing IoTgo at a distance. The
paper concludes with reflections of general interest for researchers and practitioners willing to playfully engage end
users in critical thinking about smart things and their impact on their lives.
Recruitment of participants. In all design actions with IoTgo, users were recruited on a voluntary basis by conve-
nience sampling, e-mailing education organisations and personal contacts, in conformance to the evolving COVID-19
regulations. Before all actions with minors, parents or guardians were informed and asked to state their agreement
with their child’s research participation as per regulations of the organising university.
Physical or On the Cloud: Play with IoTgo and Design Smart Things 3
2 BACKGROUND
The following section reports on playful, card-based toolkits for engaging end-users in the design of smart things. Cards
can be about motivations and goals, besides things to be made smart, and different components of smart things, such as
physical devices or cloud-computing services. Related work is outlined in the following per deck of cards, and then
according to the design stages the toolkits support.
2.1 Decks of Cards for Smart-Thing Design
Several card-based toolkits include motivation cards, related to design goals or missions. For instance, the Tiles IoT
Inventor Toolkit has mission cards which fall under this category. Examples of such missions are “create a concept that
helps to facilitate some kind of interaction between people” [12]. In the IoT Design Kit, flash cards help convey design
expectations [3]. Such cards help end users ideate while keeping in mind the scenarios, personas, context and intended
goal of a smart thing [4]. Several toolkits have missions specific to a certain context. For instance, SNaP has mission
cards for parks, e.g., “help visitors keep the park clean” [7]. IoTgo uses them as well.
Thing cards or tokens describe an environment or represent things within it. In the Tiles IoT Inventor Toolkit,
such cards are the thing cards, to be turned into smart things [12]. SNaP refers to them as environment cards. These
environment cards are similar to the Tiles’ things cards, but represent things for a specific environment, such as a
children’s park or one of its things, e.g., a swing [7]. IoTgo employs them as well, as thing cards.
Physical-computing cards are usually divided into decks of input and output cards for physical devices, for sensing
and reacting. Several toolkits have generic physical device cards. For instance, the Tiles IoT Inventor Toolkit has human
action cards, with inputs for activating smart things (shaking, tilting, rotating etc.). Smart things respond to such actions
with feedback represented by feedback cards (text, sound, vibration etc.). Such human actions and feedback can be
implemented with any technology available to end users [12]. Similarly, the IoT Service Kit has two decks of cards,
namely, sensors and interactions for defining how smart things physically interact with their environment [1]. In the
IoT Design Deck, these are called prototype cards, split into input and output cards [4].
The toolkits which are not tied to specific physical devices for input or output may offer more flexibility. However,
they also risk to lead to ideas which are not feasible to be implemented. In case end users are involved in the entire
design process, having cards that match physical devices and the environment can smooth the transition from the
ideation to the programming and prototyping stage. For instance, the Lighting User Experience (LUX) cards and Know
Cards contain cards for physical devices for specific environments [2, 10]. Similarly, SNaP has different physical device
cards, for inputs and outputs, which are selected according to the environment [7]. A similar choice is made in IoTgo.
Cloud cards constitute a broad category and usually serve to augment smart things with interaction capabilities
related to data coming from cloud-computing services. For instance, the Tiles IoT Inventor Toolkit has cloud cards for
data such as maps or news information [12]. The IoT Service Kit has cards for city services, e.g., parking data [1].
The majority of toolkits for end-users have no separate cloud-computing services or only physical-computing
services [7]. In the IoT Design Deck and other card-based toolkits, cloud-computing services are not differentiated from
the physical components of smart things, but rather categorised as inputs and outputs together with them [4]. SNaP has
no cloud cards at all, being aimed at younger children. In IoTgo, cloud-computing cards are present but separated from
physical computing cards, albeit divided similarly: one input deck for data received from cloud-computing services; one
output deck for data sent to services.
4 Gennari et al.
Ideation Programming Prototyping
Physical Cloud Physical Cloud Physical Cloud
IoTgo 1 1 1 1 1 1
Extended Tiles Ideation Toolkit 1 1 0 0 0 0
Tiles IoT Inventor Toolkit 1 1 0 0 0 0
RapidIoT with Tiles Toolkit 1 1 1 0.5 1 0.5
SNaP 1 0 1 0 1 0
SNaP Online 1 0 1 0 1 0
COBO 1 0 0 0 0.5 0
The IOT Design Kit 1 1 0 0 0 0
IoT service kit 1 1 0 0 0 0
The IoT Design Deck 1 1 0 0 0 0
Lighting User Experience 1 1 0 0 0 0
Know Cards 1 0 0 0 0.5 0
Karakuri Card Deck 1 1 0 0 0.5 0.5
Teknikio IoT Ideation Cards 1 0 0 0 0 0
IoT game ideation tool 1 0 0 0 0 0
MethodKit for Technologies 1 1 0 0 0 0
Mapping the IoT Deck 0.5 0.5 0 0 0 0
IoT Deck 0.5 0.5 0 0 0 0
Maker cards 0 0 1 0.5 1 0.5
Scratch cards 0 0 1 1 0 0
Table 1. A comparison of various toolkits with IoTgo
2.2 Supported Stages of Smart-Thing Design
Table 1 offers a bird’s eye-view of all toolkits for playfully designing with end users smart things. The table considers
whether the toolkits support different design stages (ideation, programming, prototyping) or not; in case they do, they
are scored with 1 else with 0. The table also displays whether the toolkit engages users in physical computing or cloud
computing; again 1 means they do and 0 otherwise. As the table shows, to the best of our knowledge, IoTgo is the only
playful toolkit that supports all design stages, moving end users from ideation into programming and prototyping with
physical devices and cloud-based services.
3 IOTGO AND AT-A-DISTANCE DESIGN
3.1 What IoTgo Is in a Nutshell
The IoTgo toolkit aims at enabling end users to design and reflect on smart things with physical devices or cloud-
computing services. An example smart thing is a bench (the physical thing) made smart with an input pressure sensor
and an output sound speaker (the physical devices), which senses pressure when a person seats and reacts with output
sound data, so as to accomplish the mission of making park things interact with people. The smart bench can be further
made smart with cloud-computing services, such as weather forecast data, a button for fetching them, a display for
scrolling through them and a Twitter post for communicating them.
End users start with IoTgo ideation tools of the toolkit. This has decks of game cards and boards, besides other game
elements for conceptualising smart thing ideas, and reflecting on them. See Fig. 1. Ideas, conceptualised with the ideation
tools, become the starting point for the IoTgo programming tools, these for turning ideas into working prototypes.
Physical or On the Cloud: Play with IoTgo and Design Smart Things 5
Since August 2020, IoTgo was redeveloped
starting from reflections on past actions and
considering restraints on collaboration imposed
by the COVID-19 pandemic. In particular, IoTgo
was redesigned so as to enable individuals to
use it on their own, possibly at home. However,
IoTgo tried maintaining some form of collabo-
ration, by enabling users to share ideas or pro-
grams. This section motivates and explains the
design of the latest IoTgo toolkit, and it explains
its ideation tools, besides its programming and
prototyping tools.
3.2 Ideation Tools
3.3 Cards
The latest IoTgo has iconic cards for missions,
things of the environment. Moreover, physi-
cal and cloud computing cards are rich and di-
vided into decks, separated into input and out-
put decks. Cloud computing decks are also split
according to the related services and data, so as
to have decks of: input Weather cards, e.g., to-
day’s (average) temperature; input Trivia cards,
e.g., the joke of the day; output Tweets cards,
e.g., for text Tweets; output Log cards, e.g., for
measurement data.
3.4 Ideation
Boards with Reflection Lenses
The IoTgo boards are two, the so-called physical
board and cloud board. Both are modularised
into distinct but similar levels, which are grad-
ually revealed by unfolding the boards, so as to
guide users seamlessly through:
(1) exploration and scaffolding of a smart
thing with physical devices;
Fig. 1. Game elements of the ideation tools of IoTgo
(2) reflections through lenses and questions
related to physical aspects;
6 Gennari et al.
(3) exploration and scaffolding of a smart
thing with cloud-computing services;
(4) reflections through lenses and questions
related to data exchanged with cloud-
computing services.
Each part is described in turn below.
Exploration and scaffolding of a smart thing with physical devices. The first level of the physical board contains a
pre-printed idea of a smart thing, with an URL showing a program and a simulation for it. This comes from an end user
engaged in past actions. It serves to explore and scaffold the ideation process, besides to create a sense of collaboration
among players, even at a distance. End users can change the idea or its description, if they desire so.
Reflections related to physical aspects. The unfolding of the physical board reveals reflection lenses and questions,
concerning the physical nature of smart things:
(1) Safety in the physical world: Is your idea safe or could it physically harm someone or something?
(2) Relevance in the physical world: Does the description of your idea make sense for the selected mission?
End users can add a reflection lens and questions of their own, which they use with the other lenses to revise their
smart things.
Exploration and scaffolding of a smart thing with cloud-computing services. The cloud board connects to the physical
board. The former guides end users to choose and combine cloud cards so as to enhance their smart things with data
exchanged with cloud-computing services.
Reflections related to data exchanged with cloud-computing services. The unfolding of the cloud board reveals lenses
and questions for reflecting on the smart things, augmented with data exchanged with services available on the cloud:
(1) Safety on the cloud: Consider what you receive or send on the cloud. Can it be risky or harmful to people or
things (for example, sharing personal data such as name or phone number, or making offensive jokes)?
(2) Relevance on the cloud: Does the smart thing idea, augmented with “the power of the cloud”, still make sense for
the mission?
Once more, end users can add a new reflection lens and questions of their own.
3.5 Programming Tools
IoTgo has also tools for supporting the programming and prototyping of ideas for smart things, with physical devices
and cloud-computing services. Specifically, IoTgo for programming contains visual guidebooks, empty and completed
ideation boards, these with scaffolding ideas and links to related programs by other users. Moreover, programming
tools are divided into tools for for physical computing with physical devices, and tools for cloud computing with data
exchanged with services. They are separately described in the following.
3.5.1 Physical. IoTgo contains programmable Micro:bits with a number of on-board inputs and outputs, besides further
input and output devices made easy to connect for children [11]. All physical devices are matched to input and output
cards of the ideation tools and linked to example programs with Makecode blocks.
Physical or On the Cloud: Play with IoTgo and Design Smart Things 7
Fig. 2. Cloud:bit of IoTgo: a sketch of the architecture and what players interact with to program and prototype
3.5.2 Cloud. IoTgo also contains its own Cloud:bit, developed by an IoTgo researcher. Its architecure and what players
interact with is sketched in Fig. 2. Although Micro:bits are easy-to-use and powerful, they have Bluetooth but lack
WiFi connectivity. There are a number of commercially available hardware add-ons for Micro:bits, but due to the cost
factor, proprietary choices or not-so-transparent services, they were discarded. Instead, the IoTgo Cloud:bit is developed
ad-hoc, as open-source, so as to provide a seamless and safe Bluetooth to WiFi gateway for players’ Micro:bits towards
selected and safe cloud-computing services. See them in Table 2, with the related cloud cards of IoTgo. Makecode’s
radio blocks were customised so as to enable end users to continue using blocks for programming, and transparently
sending or receiving data from or to the cloud through the gateway.
Cloud card Deck Service
Log Output Adafruit IO
Tweet Output Twitter
Trivia Input Ad-hoc
Weather Input Darksky
Table 2. Mapping from cloud cards and decks to cloud services.
4 CASE STUDY
4.1 Participants and Context
In September and December 2020, two 13-years old males used IoTgo, independently one of the other, and each with
an adult acting as observer and facilitator, so as to follow the COVID-protocol of the time. The teen participating in
September had already used IoTgo in August but was willing to try the new version. The other had used cards for
physical devices in the past with SNaP, but not IoTgo or cloud services. In December two adults, a male aged 31 and a
female aged 29 years old, used IoTgo playing together with a facilitator. Both end users had never used IoTgo and were
new to physical and cloud computing.
8 Gennari et al.
In September 2020, the teen used the entire IoTgo toolkit. In December 2020, the second teen and the two adults used
the ideation toolkit only, due to organisational constraints.
4.2 Leading Research Questions and Data Collection
This action revolved around the usage of the latest IoTgo toolkit. See Fig. 1 for the ideation tools, and Fig. 2 for a sketch
of the programming and prototyping tools of IoTgo. Leading research questions to explore were thereby as follows:
R1. if and how end users ideate smart things;
R2. if and how end user reflect across the ideation process.
Collected data were: (1) filled-in ideation boards, and programs for smart things in case available; (2) observations,
photos and recordings.
4.3 Results and Reflections
Three researchers processed data against research questions, first independently and then in joint discussions. The
main results are reported below.
R1: Design. The teen, in September 2020, appeared to feel confident with the IoTgo toolkit. He was observed to unfold
completely the novel IoT ideation boards, reporting the following: “I want to have it all open because I want to know
what I can do with it”. However, he was observed to follow the navigation cues of the game boards to the letter. He was
also observed to go through all cards, per deck, and to choose them so as to modify the scaffolding idea of a simple
smart thing, printed on the IoTgo boards. The teen realised several ideas with the IoTgo ideation tools and managed to
program one with Weather and Log independently of the facilitator, being satisfied with the result, e.g., he was engaged
with concentration and tinkered with his programs so as to explore what he could do further.
The other teen appeared confident as well. Like the other teen, he unfolded the boards. Since the very beginning, he
was curious about the next steps, as he wanted to identify a winning strategy. Nevertheless he appeared satisfied of the
unfolding mechanism: when probed about it, he reported he considered it a useful step-by-step guide. His smart thing
used Trivia and Twitter.
The two adults played together, by using a dice to take turns. Before playing, they enquired about the game rules,
and especially the winning and losing conditions. Moreover, they started soon to compete and play, e.g., the female
player complained loudly when the male player got the right dice number for taking the turn and she did not. They
were very excited to unfold the IoTgo boards and discover new tasks progressively, and they followed its unfolding
mechanism step-by-step, contrary to the two teens.
While playing the first level with physical device cards, they were observed to go though the full decks of cards
for picking up one in order to change their scaffolding idea, similarly to teens. Before changing the scaffolding idea
with new cards, the female participant discussed the relevance of the thing card for the mission she had, and why she
decided to change the former, reporting the following: “I think this thing card, the flower, fits better with the given
mission and I like the idea of creating a smart flower”. The male participant chose to maintain the scaffolding idea,
printed on the physical board. While playing on the cloud board, both complained about having limited choices on
the number of cloud-services to use and both were willing to add new cloud cards for enriching their ideas. In the
end, both managed to ideate at least one smart thing, without further scaffolding on the usage of physical devices and
cloud computing cards. For instance, the smart thing of the female participant was a flower enhanced with light and
temperature sensors, which posts related data via Twitter. The male participant used the Weather card for enhancing
Physical or On the Cloud: Play with IoTgo and Design Smart Things 9
the scaffolding idea of a smart basket. They defined the IoTgo unfolding “very funny” and one exclaimed: “Finally I’ve
got how a smart thing works”.
R2: Reflections. The teen, participating in September, was capable of reflecting with lenses related to physical inputs
and outputs, but his reflections on safety in relation to data were less developed. On the other hand, the teen created
his own reflection lens starting from the relevance lens. With the scaffolding of the facilitator, he tried to formulate a
general reflection lens and question: “do the input and output make sense, together, for the thing card?”. This goes
beyond the original question related to relevance in relation to the chosen mission, and it reminds of the feasibility lens
of SNaP [6].
The teen participating in December reflected on the safety of a smart thing for the physical part, and that he extended
with cloud services. In relation to the use of Trivia to generate sentences to be “automatically” distributed through
Twitter, he observed that the lack of control on the Trivia sentences could generate messages that could be offensive for
some recipients. This observation then led him to propose a new reflection question for the safety lens: “Can the owner
of the smart thing control what the transferred data consist of?”. More in general, this aspect refers to the control that
the users of smart things should have on the mechanisms governing the behaviour of their devices, especially when
data communication is involved.
Adults managed to reflect without any major issue with the given reflection lenses and companion questions. On
the physical board, the female adult argued extensively why the created smart thing is safe, providing examples. The
male adult needed further scaffolding by the facilitator concerning safety, and then he was able to reflect on his choice
and tackle the safety reflection lens independently. On the cloud board, the female adult reflected on the Twitter card
extensively, and discussed the possibility to have a legal and private account for Twitter which avoids dangerous tweets:
“If there is a private Twitter page for the park, there will be no risks” (it is in fact so). For the reflection lens related to
relevance, both adults were able to reflect on it independently of the facilitator, and they elaborated on it. As for new
reflection lenses, the male adult reflected on his smart thing in terms of accessibility and potential discrimination issues.
5 CONCLUSIONS
This paper intersects growing concerns related to smart things, and their responsible design. Responsible design requires
developers technical skills and to reflect in design with diverse lenses, which consider the impact of technology on end
users. However discourses around design and reflections in design often fail to see end users as active participants.
Engaging them in design and reflections has several potential benefits, e.g., making them aware of risks.
Although there are tools for imagining new smart things or for programming smart things with end users, and
especially teens, there is less research on tools that engage them to ideate and program their own smart things, besides
to reflect across their design. This paper addresses it. It presents the IoTgo playful toolkit, guiding end users across the
design of smart things and reflections on their physical nature and data exchanged with cloud-computing services. This
paper outlines the evolution of IoTgo and focuses on the latest evolution during the COVID-19 pandemic. Limitations
of the work are due to its qualitative nature and restraints imposed by the pandemic.
Overall, the research reported in this paper could provide researchers and practitioners with: (1) the description
of a novel playful toolkit, IoTgo, which enables to disclose design and reflection possibilities with end users (physical
and on the cloud); (2) a description of how it evolved across a pandemic, leading to reflections of general interest,
contextualised and interpreted in light of the reported work; (3) room for discussion concerning how to scaffold design
with end users, especially teens, and engage them in shared reflections across design.
10 Gennari et al.
ACKNOWLEDGMENTS
We wish to thank all end users, participating in design actions, as well as parents and the designer of SNaP cards.
REFERENCES
[1] Ricardo Brito and Paul Houghton. 2017. IoT Service Kit. http://iotservicekit.com. Accessed: 2019-09-06.
[2] Kyungah Choi, Taesu Kim, and Hyeon-Jeong Suk. 2020. Lighting User Experience (LUX) Cards: A Card-based Tool for the Design of Smart Lighting
Solutions. Archives of Design Research 33 (02 2020), 55–64. https://doi.org/10.15187/adr.2020.02.33.1.55
[3] Dries De Roeck, Jürgen Tanghe, Alexis Jacoby, Ingrid Moons, and Karin Slegers. 2019. Ideas of things: The IoT design kit. DIS 2019 Companion -
Companion Publication of the 2019 ACM Designing Interactive Systems Conference (2019), 159–163. https://doi.org/10.1145/3301019.3323888
[4] Massimiliano Dibitonto, Federica Tazzi, Katarzyna Leszczynska, and Carlo M. Medaglia. 2018. The IoT Design Deck: A Tool for the Co-design of
Connected Products. In Advances in Usability and User Experience. Springer International Publishing, Cham, 217–227. https://doi.org/10.1007/978-3-
319-60492-3_21
[5] Virginia Dignum. 2019. Responsible Artificial Intelligence. Springer International Publishing, Cham. https://doi.org/10.1007/978-3-030-30371-6
[6] Rosella Gennari, Maristella Matera, Alessandra Melonio, Mehdi Rizvi, and Eftychia Roumelioti. 2020. Reflection and Awareness in the Design
Process Children Ideating, Programming and Prototyping Smart Objects. Multimedia Tools and Applications (2020). https://doi.org/10.1007/s11042-
020-09927-x
[7] Rosella Gennari, Maristella Matera, Alessandra Melonio, and Eftychia Roumelioti. 2019. Research on Making Nature Smart with Children. In
End-User Development. Springer International Publishing, Cham, 249–253. https://doi.org/10.1007/978-3-030-24781-2_25
[8] Rosella Gennari, Alessandra Melonio, and Mehdi Rizvi. 2018. Evolving tangibles for children’s social learning through conversations: Beyond
turntalk. TEI 2018 - Proceedings of the 12th International Conference on Tangible, Embedded, and Embodied Interaction 2018-Janua (2018), 368–375.
https://doi.org/10.1145/3173225.3173248
[9] Marianne Kinnula and Netta Iivari. 2019. Empowered to Make a Change: Guidelines for Empowering the Young Generation in and Through Digital
Technology Design. In Proceedings of the FabLearn Europe 2019 Conference (Oulu, Finland) (FabLearn Europe ’19). ACM, New York, NY, USA, Article
16, 8 pages. https://doi.org/10.1145/3335055.3335071
[10] Know-Cards. 2019. Learn. Play. Collect. - Know Cards. https://know-cards.myshopify.com. Accessed: 2019-09-06.
[11] Micro:bit-Educational-Foundation. 2019. Micro:bit Educational Foundation | micro:bit. https://microbit.org. Accessed: 2019-09-06.
[12] Simone Mora, Francesco Gianni, and Monica Divitini. 2017. Tiles: A Card-based Ideation Toolkit for the Internet of Things. In Proceedings
of the 2017 Conference on Designing Interactive Systems (Edinburgh, United Kingdom) (DIS ’17). ACM, New York, NY, USA, 587–598. https:
//doi.org/10.1145/3064663.3064699
[13] UNICEF. 2020. Policy guidance on AI for children.
[14] VIRT-EU Consortium. 2021. VIRT-EU. https://www.virteuproject.eu/servicepackage/