TINK - sketching product experiences of connected objects

sketching product experiences of connected objects

A master thesis by
Lorenzo Romagnoli
Supervised by
Elisa Giaccardi
Aadjan van der Helm
July 2014

Introduction
This paper is a summary of my graduation
project, for the master in Design for
Interaction at TUDelft. The project was
carried out in the environment of the
IDStudiolab, a design research community
of the Faculty of Industrial Design
Engineering, between November 2013 and
July 2014.
The given assignment was to design
a tool to support designers building
experiential prototype of connected
objects.
The report goes trough the process that I
followed during this 7 months.
In Chapter 1 the boundaries of the project
are introduced: The topic of sketching
user experiences and design tools will be
investigated. In the end of the chapter a
working definition for “Connected Objects”
is presented.
In Chapter 2 the market analysis done along
the project is presented: a categorization of
Connected Objects is proposed and several
tools aimed at supporting the development
of interactions with this kind of products
are analysed.
At the end of the chapter initial design
directions are presented.
In Chapter 3 a user research carried out with
interaction design students is discussed:
the study was aimed at understanding the
level of knowledge interaction designers
have about connected objects and how
interaction designers are able to draw
system diagram of complex systems of
connected objects.
The research, combined with the findings
from the previous analysis led to the
formulation of a program of requirements.
In Chapter 4 the reader is introduced to
TINK, the final design of this project:
TINK is a web application to connect
objects one to an other via the Internet,
the platform is composed of two main
components:
• The first one is used to sketch system
diagrams and define the behaviours
of the connected objects and of the
different entities involved in the
design.
• The second one is used to monitor the
system, track and visualize data.
In Chapter 5 the setup used to evaluate
the platform is presented.
Two prototypes where built in order to test
the technical feasibility of the platform
and the user experience. The setup and the
results from the user test are discussed at
the end of the chapter.
In Chapter 6 an evaluation of the design is
proposed. The main contribution that TINK
brings to the field of interaction design
are explained followed by a reflection on
the program of requirements introduced in
chapter 3, and a list of recommendation for
future developments.

Table of contents
CHAPTER 1 9 CHAPTER 2 29 CHAPTER 3
55
Graduation assignment Market analysis User research
1.1 Sketching for Interaction
design
1.1.1 Sketching with code
1.1.2 Sketchy qualities
1.1.3 From sketches to prototypes
1.1.4 Terminology
1.1.5 Graduation Assignment
INSERT Sketchy programming tools
INSERT Sketching an animated pattern
using processing
1.2 About tools
1.2.1 A philosophical perspective
on tools
1.2.2 design tools
1.3 The Internet of things
11
11
14
15
17
18
10
13
19
19
24
26
2.1 Communication model for
Connected Objects
2.2 Categories of Connected
Objects
2.2.1 Objects linked to digital data
2.2.2 Objects that publish data to
the web
2.2.3 Objects that pull data from
the web
2.2.4 Remote controlled Objects
2.2.5 Bidirectional communication
devices
2.2.6 Objects networks
2.3 Connected Objects toolbox
2.4 Tools users
2.5 Technology archetypes
30
32
34
35
36
37
38
39
40
42
44
3.1 Research questions
3.2 Research setup
3.3 Research results
3.4 Discussion
3.5 Program of requirements
56
57
60
63
64
2.5.1 Hardware
2.5.2 Software
2.5.3 Hardware + software
45
48
50
2.6 Design directions
52

CHAPTER 4 67 CHAPTER 5 83 CHAPTER 6
97
Final design Testing Evaluation
4.1 Sketching TINK
68
5.1 Prototyping TINK
84
6.1 Main contribution
98
4.2 Project view
4.3 Edit view
4.4 Monitor view
4.5 Workflow
70
72
76
78
5.2 Connecting a coffee
machine to the Internet
5.3 prototyping the user
interface
5.2 User test
86
88
90
6.2 Reflection on the program
of requirements
6.3 Recommendations
6.4 Personal evaluation
100
102
106
4.6 Tink technology
80
5.2.1 User test goals
5.2.2 User test setup
5.2.3 User test results
90
90
92

8 - TINK
Figure 1. Bill Verplank (2001),
Interaction designers have to find answers to three questions:
How do you do? How do you feel? How do you know?

Graduation Assignment - 9
CHAPTER 1
Graduation assignment
In this chapter the boundaries of the project and the graduation
assignment are presented.
1. SKETCHING is considered the main activity designers are engaged
with 1 ; I’ll explain how this practice goes beyond drawing with markers
on paper, and what are the characteristics of it.
2. I’ll then analyse TOOLS, and the role they play for designers.
3. I’ll then discuss the broad topic of the INTERNET OF THINGS 2
(IoT). I’ll propose several definitions from literature in order to define
the domain and the boundary of the project. At the end of the chapter,
a working definition for “Connected Objects“ is introduced.

10 - TINK
SKETCHY PROGRAMMING TOOLS
The images below show two different IDE, Eclipse on the left, and Processing on the right.
The software written in JAVA in the Eclipse IDE produces the same result of the few
lines of code written with Processing: the simple ellipse on white background shown in
the third window. It should be clearer already how easier it is in Processing to display
graphics therefore allowing quicker development and more iterations.
The two software differ a lot also in the interface, while Eclipse interface provides several
panels and several buttons and options, Processing interface presents just few buttons:
the most important of them, the play button, is the one that runs the sketch, during the
development of a processing sketch it is going to be pressed several times in order to get
a feedback on the result of the modification on the code.
Figure 2. Comparison of Eclipse and Processing IDE

Graduation Assignment - 11
1.1 Sketching for interaction design
1.1.1 Sketching with code
In my bachelor program in “Cinema and
New Media Engineering”, I learned Java,
an object-oriented programming language,
meant for cross-platform development.
It isn’t a very difficult programming
language, however as most as other
classical programming languages, it is
quite structured. It was my first encounter
with a programming language, and it
required me to acquire knowledge on
different levels: I had to learn lexicon,
syntax, programming logic, programming
paradigms, and programming tools.
In my first programming course,
programming graphical user interface was
not covered. It wasn’t until a later and
more advanced programming course that
this topic was addressed. Each week’s
assignment was to design a specific
video game. Programming the Graphical
User Interface (GUI) for these games
required learning more lexicon but also
new programming patterns. Displaying
something on screen in Java was not that
straightforward. Lots of libraries had to be
imported and some difficult constructs had
to be implemented.
I gained an entirely new perspective the
first day I started using Processing, a
programming language for designers and
artists to program images, animation,
and interactions 3 . When I discovered that
just a line of code was needed to draw an
ellipse on screen, I was motivated to keep
programming to explore what else I could
do with it.
I was inspired by that platform that made
programming complex graphics quick and
easy. My programming knowledge was
still useful; processing is in fact based
on Java. The difference between the
two is that Processing hides most of the
complexity required by Java. Processing’s
fewer lines of code, is an improvement
in efficiency: it is faster, there are fewer
opportunities to make mistakes, and as a
result programming flows more smoothly
and is much more explorative. The absence
of Java’s structured, boilerplate formatting
makes Processing much more enjoyable.
The way I learned how to program was
mainly taught in my Bachelor as a way
to solve problems. The practice of coding
started always with understanding and
deconstructing the given assignment, the
deconstructing was done on paper, where
the structure of the program was sketched.
Once the program was clear on paper and
in mind it was translated in code. The
sketch on paper has to be correct. In that
depends the effective translation of the
project in to code.
The process of coding described doesn’t
allow for any creative exploration: from a
good programmer is in fact required to gain
complete awareness about the software he
will have to write before start coding: a

12 - TINK
SKETCHING AN ANIMATED PATTERN USING PROCESSING
How to represent information trough the most unobtrusive moving pattern
was the goal of this project. In particular it was required to use moving
pattern to represent the emotional state of 5 best friends.
The figures on the left are screenshots of different software developed along
the design process before getting to the final result.
I started thinking at creating moving pattern like the one created for
aerodynamic simulations.
A first sketch was developed in Processing featuring a moving effector that
was displacing dots on the screen according to its position. The dots got then
connected by lines in order the resulted effect is show in the first image
It was thought that using different styles to connect the dots to each other
and having different displacement styles could provide enough material to
represent different emotions. It was decided to make a new software where it
would have been possible to change those parameter on the fly and test how
people would react to the different visualization.
The iteration provided enough insights to proceed with the development of a
new version of the software. The movement of multiple elements on the grid
would have made a really confusing visualization. Therefore it was decided
to keep those in fixed position and instead have the grid sliding to create to
create the movement.
A sense of presence of multiple entities was given by having hidden entities
that affect the grid by growing an diminish their interference resembling a
breathing.
It was observed that the breathing was perfect in giving some sort of agency
to the grid, however it was thought that by having more control on the
dynamic of the breathing could have gaining a higher level of expressivity.
This lead to the final version of the software where all the parameter could
be modified via the interface. With the software it was then able to prototype
the behaviour of the movement for 5 different emotions and test them with
participants
Figure 3. Emotional Lockscreen (2013)

Graduation Assignment - 13
bad structure or no structure might lead
to errors and problems that might end up
making him waste hours, days or months
of work.
The process of developing programs with
Processing is instead less structured; I
often just start by writing some lines of
code, compile the program and check the
result on screen.
Of course I kind of know what to expect
from the code I write, but having the
possibility to see the development of my
work create a sort of dialogue between the
software and me. I iteratively react to what
I see on screen moving from a simple idea
to a more structured concept.
I write a lot of spaghetti code, I don’t in
fact care about performance or at how am
I going to extend the software. Especially
in the first stages of the project I just
want to explore different possibilities, this
often lead to make me restart writing the
software from scratch several times before
I get to a “final version”.
In order to iteratively improve and react
to the sketches, is very important to have
direct feedback of the result of the code
you are writing 4 . In fact while the practice
of sketching on paper is very direct, in the
sense that you immediately see what you
are producing, the code is an abstraction
(a description) of the final result, that the
developer most of the time envision have
to envision in his head.
Developing programs in processing is for
me the exact equivalent of sketching with
code: I draw bunch of lines, I see how it
goes and then I try to improve. Sometimes
I discover that I have to start from scratch
because the image produced or even just a
movement just created gave me a complete
new idea.
The dialogue between the programmer and
the code results in a creative process very
similar to the one that happens when an
artisan crafts a piece of wood, and the one
between a designer and the material he
uses.

14 - TINK
Table 1.
Sketchy qualities,
Buxton, B. (2010).
Sketching User Experiences
1.1.2 sketchy qualities
Processing files are called sketches. The
metaphor doesn’t only refer to the fact
that the programming language is primarily
aimed at the development of visual
materials, it also describes other important
characteristic of it:
Table 1 presents a list of relevant attributes
characterizing conventional sketches as
analysed by Bill Buxton.
Processing embeds several of the
characteristics of the table:
Programming in Processing is in fact way
faster than using other programming
languages, this promotes the exploration
of several ideas.
By tweaking some variables in the code
different results can be achieved in the
visualization. This can lead to unexpected
errors that might inspire the designer in
exploring new paths.
The level of detailing of a processing sketch
can be defined by the programmer.
Processing sketches as they are programmed
quickly are often rebuilt from scratch as
soon as the ideas get more concrete along
the design process.
At this point Someone might argue that
processing is for me a great sketching tool
just because I have good programming
skills; while more insight about the relation
between tools and designer will be given
later in this chapter, I’d like to state that
even though a pencil might be considered
a great tool for sketching, some skills are
required in order to draw with it. For me in
Quick:
A sketch is quick to make, or at least gives the impression that that is so.
Timely
A sketch can be provided when needed.
inexpensive
Disposable
Plentiful
Clear vocabulary
A sketch is cheap. Cost must not inhibit the ability to explore a concept, especially early in the design process.
Sketches are disposable. If you can’t afford to throw it away when done, it is probably not a sketch. The investment with a sketch
is in the concept, not the execution.
Sketches tend to not exist in isolation. Their meaning or relevance is generally in the context of a collection or series, not as an
isolated rendering.
The style in which a sketch is rendered follows certain conventions that distinguish it from other types of renderings. The style,
or form, signals that it is a sketch. The way that lines extend through endpoints is an example of such a convention,or style.
Distinct gesture
Constrained resolution
Appropriate Degree of
Refinement:
Not tight. Open. Free.
Sketches are not rendered at a resolution higher than is required to capture their intended purpose or concept. Going beyond
“good enough” is a negative, not positive. (Which is why I take marks off student’s work if it is too good.)
The resolution or style of a sketch’s rendering should not suggest a degree of refinement of the concept depicted that exceeds the
actual state of development, or thinking, of that concept
Ambiguity:
Suggest & explore rather
than confirm
Sketches are intentionally ambiguous, and much of their value derives from their being able to be interpreted in different ways,
and new relationships seen within them, even by the person who drew them.
More on this later, but sketches don’t “tell,” they “suggest.” Their value lies not in the artefact of the sketch itself,
but its ability to provide a catalyst to the desired and appropriate behaviours, conversations, and interactions.

Graduation Assignment - 15
fact sketching on paper turns out to be as
frustrating as programming is for most of
the people with no programming skills
1.1.3 From sketches to
prototypes
In common design practice, “sketches”
commonly refers to conventional
drawings on paper. Words like “model” or
“prototype” are commonly used to describe
any other types of rendering outside of
the sketchbook. Although those words
are often used interchangeably, I’d like
to point out an important distinction
between the two:
Models can be either virtual or physical,
and are often scaled three-dimensional
representation of a design.
Prototypes, on the other hand, are more
refined and functional renderings of the
final product that is built to be tested. 1
In this terms, a model can be considered
equivalent to a three-dimensional sketch;
whereas a prototype is a usable, testable
sketch. In figure 4 Buxton proposes a list
of attributes characterizing the differences
between sketches, which are open,
explorative, and suggestive representation,
while a prototype instead in more definitive
representation with details.
Figure 5 represents a typical interaction
design process that starts with the
ideation phase and ends with an evaluation
Figure 5. The Dynamics of the
Design Funnel
Buxton, B. (2010).
Sketching User Experiences
Figure 4.
Differences between sketches
and prototypes
Buxton, B. (2010).
Sketching User Experiences

16 - TINK
Figure 6. The aim of the project, commissioned bi NCR was to design and build a fully working
prototype of a “kind cashpoint”. Along the process several sketches, both on paper and physical,
were iteratively produced before getting to the level of refinement of the experiential prototype
shown in the big picture.

Graduation Assignment - 17
phase. Along the process, through several
iterations, the designer moves from ideas
to formulating a concept, to refinement
of that concept, and then detailing and
designing the final product.
Different kinds of sketches are used trough
the all process: in the beginning of the
process a lot of sketches are done quickly
as an explorative technique to support the
ideation phase.
When the idea develops, tests are
conducted to evaluate and improve the
design. Several aspects of the interaction
might be tested separately and integrated
together in the next steps. At the end the
integration of the different component of
the design (such as materials, aesthetics,
interface…) will result in a product that
will look, feel, and behave very similar to
the one that is going to be produced.
A sketch with this level of detailing is
defined a prototype.
The sketches done along an iterative design
process are not just conventional paper
sketch, but they can assume different
forms according to the features that have
to be understood, experimented, and
tested. The sketch might take the shape of
a clay model, a mechanical contraption, or
a website.
While the practice of sketching is
fundamental in every design practice, in
the field of interaction design, sketching
covers even a more important role. If it is
in fact possible to understand the visual
aesthetic of a juicer from a rendering, it is
impossible to experience how that object
will feel like and will behave in your hands
without a model, a prototype.
1.1.4 Terminology
The semantic problem between the use
of the word “sketch” and “prototype”
in the interaction design practice and in
theory must be solved in order to avoid
misunderstanding along the rest of the
report.
Two useful concepts have been identified
to refer to those artefacts that are built
along the design process and go beyond
the conventional paper sketch but still
don’t present the accuracy of a prototype.
The practice of “sketching in hardware”,
refers to the strong sketchy, almost messy
and more designerly connotations, has
the benefit of emphasizing the material
and experimental qualities 5 . On the other
hand, “experiential prototyping” highlights
that the goal is to design and support the
experience and not the prototype (or the
built artefact). 5
I will use in the concept of “experiential
prototype” in the rest of the report as
it provides more flexibility to describe
the spectrum of sketchy and less sketchy
artefacts produced along the design
process to describe physical representation
of the design developed with the scope of
testing a part or the entire interaction.
Moreover, this term is the one commonly
used within the TU Delft design community
to describe to this practice.

18 - TINK
1.1.5 Graduation assignment
The designer’s toolbox has been enriched
in the last 15 years with all sorts of tools
to realize experiential prototype, such as
Processing. However, in the emerging
field of the Internet of things (IoT) very
few tools designed to address the specific
needs and varied levels of competencies of
interaction designers. 5
Because of the level of complexity of the
systems designed in the area, most of the
tools currently available are designed by
engineers for engineers. As a result, these
tools require significant expert knowledge
in programming, electronics and signal
processing.
Tools targeting engineers are built on the
assumption that the user of the tool knows
exactly what is he going to build and how
is he going to do it. Instead, in order to
support interaction designers, there is a
need for tools with “sketchy” qualities:
tools that are versatile, rapid to use, and
that encourage and support exploration.
Those consideration lead to the formulation
of a graduation assignment:
Design a tool that supports the sketching and interactive prototyping of IoT products.
The tool should be suitable for education as well as professional design practice.
This tool should not require expert knowledge in programming, electronics, and signal
processing; rather it should allow interaction designers to tinker with their ideas and
stay focused on their creative process. It should enable interaction designers to sketch
the interaction they may envision among data, people, and one or more physical objects
without having to bother about technical details. However, it should be designed so to
satisfy the needs of both first-time and advanced users 6 .
The tool won’t just help interaction designers overcome technical problems, but it will
also enable them to explore new possible interactions arising from interconnecting
data and objects.

Graduation Assignment - 19
1.2 About tools
1.2.1 A philosophical
perspective on tools
According to Heidegger, a tool is
“something in order to…” it has therefore
to be useful, helpful and serviceable. 7
Technology, however, has “no essence”
according to Hilde. Tools come into essence
through their concrete use. 7 This means
that the same artefact can have different
identities in different contexts of use. Hilde
refers to this property that tools embed as
multi-stability: A hammer can
be used to nail something in
to the wall, but also to prevent
paper to fly away. In the two
different situations the value
we attribute to the object is
different.
While all objects are multistable,
users interacting with
objects are never aware of the object
condition. 7 Tools are in most of the cases
experienced as invisible. Their essence is
not apparent, as it is not in use:
While typing on a keyboard, we don’t take
in to account the action of typing; our
thoughts are not even directed to the final
goal of our interaction: that is translating
thoughts into words that are appearing
on a screen. We are just engaged in this
activity.
In the moment we interact with a tool to
accomplish an action, the tool became an
extension of our body. 8
The only moment we reflect on the
Tools are in
most of the
cases
experienced
as invisible.
materiality of the tool is when it misbehaves
or it stops working. 7 In this moment, the
tool is not experienced anymore as an
invisible extension of ourselves but as
something extraneous. In that moment the
mediating role that the tool had on our
interaction becomes clear.
Are tools all of a kind?
If we look at tools just from a functional
point of view, most of the tools that can
be found around us were designed with
specific scopes: A lamp is used
in order to be able to see in the
dark, a watch is used to keep
track of time and a telephone
to talk to people over long
distances.
Some tools are different. A
Swiss army knife, for example,
is a tool that doesn’t prescribe
a specific use, it is in fact “multi-purpose”.
The Swiss army knife is not a good knife, is
not a good scissor, nor a good corkscrew.
However, it is a very well designed tool: it
is easy to carry around, lightweight, and
therefore useful in several situations.
The multi-purpose knife differs from a
kitchen knife because it was designed with
openness in mind; while the kitchen knife
was optimized according to ergonomic
principles and different cutting styles for
kitchen use, the Swiss army knife was
optimized to be serviceable in different
contexts, compact, and lightweight.
As already discussed, all objects are

20 - TINK
multistable: they can assume different
meanings and purposes depending on the
contexts of use. 7
Our Swiss army knife, however, which was
designed to operate in many different
contexts and perform many different
functions, goes beyond the definition of
multistability, we could almost claim that
this object is
Multistable 2
Multi-purpose tools are Multistable 2 as
they are not designed to accomplish one
specific function but many at the same
time.
In this sense it can be stated that they
are “more open” and therefore they can be
used in different ways in different contexts,
and therefore acquire different meanings.
A light bulb, for instance, is an object
designed to illuminate a space. Its reason
d’être is very specific, but still it can
assume different meanings according to
the use we can make of it. The light bulb
on top of the kitchen table acquires a
different meaning from the bulb placed in
the corridor because of the different types
of activities and behaviours that it can
facilitate in those spaces.
This value, in terms of the behaviours
and activities a light bulb can facilitate,
is especially apparent when it burns out
and no longer works. When a light bulb
is broken, it comes out of its state of
invisibility and asks for intervention.
While the malfunctioning lamp in the
kitchen urges to be replaced quickly, it will
probably take us longer time to remember
to buy a new bulb for the corridor. We are
triggered to replace the bulb in the kitchen
as soon as possible because we realized
that the functioning bulb in the kitchen
facilitates social interactions and relations
that tend to be centred in the kitchen, the
heart of many households.
In the moment of the replacement we
are also engaged with the materiality
of the object: we experience the bulb as
something physical, not just as “an object
in order to…”, we reflect on the shape it
has and on how to replace it. 7
Once the bulb has been replaced it goes
back to its invisible state. We are no
engaging with it consciously. The lamp will
keep on accomplishing its role without us
to realize about the value it gives to our
lives.
In figure 8, Lampada Arco by Piergiacomo
and Achille Castiglioni is shown. If we
analyze it just in functional terms, Lampada
Arco and the generic tungsten light bulb
serve exactly the same task; but these
two products are very different from each
other. While Arco was designed with a very
specific context in mind, the generic light
bulb was designed to be used inside the
Castiglioni brother’s famous lamp as well
as in millions of other lamps. Analyzing the
differences between these two products in
terms of engagement, we discover that
while the light bulb, as already discussed,
keeps you engaged just in the moment you
have to replace the bulb, Lampada Arco
offers several ways in which it can engage
with the users.

Graduation Assignment - 21
Figure 7. swiss Army knife
(1884), Victorinox

22 - TINK
We might think that the Arco’s design is
something with a very little “openness
level” as the design is very explicit and has
a very specific function. However the lamp
was designed to be very flexible responding
to the need of dynamism required by modern
houses. The shape of this lamp makes it
possible to produce light on a table without
the need of hanging from the ceiling. As
it is not hung from a ceiling, it makes it
possible owners to change the layout of
the room without being concerned about
drilling holes and changing the wiring. The
lamp is easily moved and transported via
a hole in the marble block that serves as
the lamp’s base. The hole is placed in the
marble block’s centre of gravity, the owners
can easily lift the lamp using a broomstick
inserted in the hole. The lamp can also
transform its shape, the long arm can be
extended or retracted to adjust its height.
Lampada Arco is targeting end user, people
willing to buy the lamp and put it in their
houses. The light bulb is targeting both end
user and designers: the end user needs to
buy a bulb in order to replace a broken one;
lamp designers have to design their object
around the light bulb and must consider
its shape, size, luminosity, temperature it
might reach etc.. In this sense a light bulb
becomes a material for the designer.
From a sensorial point of view, the
elegance and simplicity of the shape, and
the materials can be appreciated.
In my personal experience however this
kind of lamp also provides an additional
level of engagement since I recognize the
iconic value this lamp has in the history
of Italian design, I appreciate the ideas
that give shape to the product. All the
contextual information I know about the
product makes me value the product even
more. 7 I am engaged with it and appreciate
the product in the same way I can be
engaged by an art piece.
While the light bulb and Lampada Arco
are serving the exact same task, they are
targeting two different user groups. While

Graduation Assignment - 23
Figure 8. Lampada Arco (1962), Achille Castiglioni, Piergiacomo castiglioni for Artemide

24 - TINK
1.2.2 design tools
Pieter Jan Stappers’s work comes useful in
my attempt to categorize different kinds of
objects.
The sketch in figure 9 consists of a number
of layers of design, each named after the
main actor in it. Stappers refer to these
as ‘meta-levels’, which help us understand
how tools, the people that use them, and
the process of design are inter-related:
When we apply meta levels to
design, we have users of tools we
call products, designers of those
products who use ‘design tools’,
and people who create those tools,
sometimes referred to as ‘design
researchers’ or ‘methods developers’ 9
Within this schema, the Lampada Arco can
be placed as a tool designed by product
designers for consumer; the light bulb
instead stays on a superior level and have
the role of design tool that the product
designer need to use when has to design
a new lamp.
Openness comes with a limitation:
In order to operate those kinds of “open
tools” some skills are required. For example,
in order to replace the light bulb, we need
know how to replace the bulb within lamp.
Similarly, the knife of the Swiss Army Knife
is a multipurpose tool not specifically
designed to cut bread, but as it is an open
tool, it can if we manipulate it in order to
accomplish the task.
In the same way product designer
starts designing a product by defining
requirements based on user research,
designers of tools should start from a
good understanding of their users: product
designers.
Design tools in fact should be designed
based on the expertise designers have 6
and be able to integrate smoothly into
their design process. Design Tools should
empower designers, requiring from them
a minimum effort in acquiring new skills
that are not part of their main expertise. 6
Generally speaking we can state that a
bigger level of openness in a product
makes it serviceable at a higher level of
meta-design. Design tools have therefore a
bigger level of openness since they have to
allow product designers to use them in as
many projects as possible.

Graduation Assignment - 25
Figure 9. Meta-levels in design Stappers, P. J. (2009). Meta-levels in Design Research.

26 - TINK
1.3 The Internet of Things
In the last 10 years microcontrollers
have become smaller in size, more energy
efficient, and cheaper. Consequently, it
has become possible to embed them into
everyday objects. 10 As a result of this
technological development, large and small
companies have started to connect everyday
objects (from dishwashers to umbrellas) to
the Internet. This has created a ubiquitous
connection between the physical and the
digital world: a new social web in which
both people and objects communicate.
This web of interconnected and responsive
objects is commonly referred to as the
Internet of Things 2 .
The IoT is a hard to define precisely. In
fact, many different groups have already
tried to define the term, although its
initial use has been attributed to Kevin
Ashton, an expert on digital innovation.
Each definition shares the idea that the
first version of the Internet was about data
created by people, while the next version
is about data created by things. In 2009,
Ashton said it best in this quote from an
article in the RFID Journal 2 :
“If we had computers that knew
everything there was to know about
things - using data they gathered
without any help from us - we
would be able to track and count
everything, and greatly reduce waste,
loss and cost. We would know when
things needed replacing, repairing
or recalling, and whether they were
fresh or past their best”.
Other authors have tried to come up with
other names and definitions to highlight
particular aspects of IoT objects. For
example, Bruce Sterling talks about
“Spimes” highlighting the way those object
can be tracked:
“Things that are searchable, track
their location, usage histories and
discourse with the other things
around them”. 12
Julian Bleecker instead, embracing Latour’s
actor network theory, refers to those kinds
of objects as “Blogjects,” emphasizing
the capabilities for this object to produce
contents:
Blogjects became first class citizens
with which we will interact and
communicate, they won’t just be
things connected to the internet
but things participating within the
internet. 11
Kuniavsky on the other hand underline the
pervasive computing aspect that those
object embed and highlights their ability
in processing information. He refers to
them as “smart things” and defines it as:
“Things that do information
processing and networking, but are

Graduation Assignment - 27
not experienced as general purpose
computing or communication
devices.” 10
Boreland instead defined “meta products”
as:
“Information fueled products and
services that will be around us as a
network whenever we need them” 13
In this definition the element of
pervasiveness is present, but it additionally
provides that those products are always
connected to services, and that they are
powered by data and information.
It is clear after this overview how the Broad
domain is still not defined yet. In order
to be able to operate in it I formulated a
statement that summarizes several aspect
of the definition just discussed in a more
practical formulation.
To the internet
Embed computers
Store information
Propose decision
connected
objects
inform
decisions
To the enrironment
Object looking
To other objects To people
Produce information
Take decision
Figure 10. Definition of Connected Objects
I will use the name “connected objects” to refer to
objects that are somehow connected to the Internet,
to other objects, and to people. Connected objects
are able to contain and/or create information.
These objects don’t necessarily look like computers,
even though they have microcontroller inside.
Connected objects are able to make decisions or
influence our decisional process.

Figure 11. Make magazine vol 36 (2014)

CHAPTER 2
Market analysis
In the beginning of the chapter, a COMMUNICATION MODEL to
analyse different kind of IoT products is proposed.
Market research was conducted to define more concretely what
kind of objects fall in the category of “Connected Objects.” 70
projects where analysed with respect to the communication
model, and grouped into 6 CONNECTED OBJECT PRODUCT CAT-
EGORIES.
A similar analysis was conducted on the tools designed to
support the creation of experiential prototypes of connected
objects. The tools have been deconstructed according to their
features, and thus 9 TECHNOLOGICAL ARCHETYPES are defined
here within.
TARGET USERS for the different tools are identified.
At the end of the chapter the first design directions are
presented.

30 - TINK
2.1 Communication model for connected
objects.
Figure 12. Wall Analysis of Connected
Objects
After having acquired a theoretical
knowledge on the topic of IoT, an analysis
was conducted on 47 research and design
project in order to gain a more practical
understanding on the topic.
The list of projects was initially retrieved
from a research done by Emma Gores and
Elisa Giaccardi on socially tangible media.
In order to have a complete picture of
different kind of IoT products other 23
projects where then added to the initial
set.
A system diagram was drawn for each
project analysed, a special focus was given
in mapping out the connections between
the different elements involved in the
system.
As a first result of the analysis five entities
were identified as recurring actors that
are most of the time present in systems
of connected products. This 5 entities
communicate and exchange information
between each other in a fixed structure.
Figure 13 shows a communication model
representative of how information can flow
between the different entities. The flow of
information is also representative of how
the different entities interact with each
other.
Objects
In a pervasive technology perspective,
objects are the one that, equipped with
sensors, actuators, micro controllers and
networking capabilities, evolve. They
become able to contain, create, share
information and sometimes take or suggest
decision. In this perspective objects are
actively taking part to a conversation with
users.
Other objects can mediate interaction with
connected objects. Those will be touch
point of the same system. For example a
system can be composed of an object that
post data on the Internet, the data can
then be fetched through a web browser or
displayed via an other objects.
Data
Data is the base element of an informational
system. 13 Data can be recorded by sensors
embedded inside objects or produced
directly by people in the digital world.
Data can be transmitted from object to
object, stored and analysed. Data enables
the system to be smart.
Users
Without users, systems do not need to
exist. All systems are designed around
users, who produce data or make valuable
use of information collected via objects
and devices.
Users never have direct access to data,
their access to the information stored in
to the cloud is always mediated by either
objects or devices

Market analysis - 31
Devices
The device, or multi-purpose device can be
a smartphone or a laptop. In most cases it
has a screen and an interface that allows
people to visualize and manipulate digital
information.
While objects can manipulate and present
data as well, object are, in most cases,
very specialized things. Devices are not
specialized but multi-purpose. Different
programs/apps can be installed on them
allowing endless possibilities.
Places
Places serve as stages for the
interaction to happen. Object can
have direct interaction with users, but
they can also can interact with their
users indirectly by affecting people’s
environment.
Places in fact can be controlled,
monitored and modified by objects.
DEVICES
PEOPLE
DATA
OBJECTS
Figure 13. Communication model
for Connected Objects
PLACES

32 - TINK
2.2 Categories of
connected object
Different system of Connected Objects are
characterized by a different communication
flow: the stream of information going from
one entity to another can follow different
paths.
For instance having a smart watch that
collects data and stores it online presents
a clear information flow that starts from
the user that generates the data -> the
device that reads the data and logs it->
and a database (cloud) where the data is
then stored.
6
actuator
sensor
actuator
sensor
BIDIRECTIONAL COMMUNICATION TOOLS
KISSINGER
LUMITOUCH
The projects analysed were grouped in
6 categories according to the kind of
communication flow implemented.
The categories are not mutually-exclusive,
and some overlaps can be identified.
5
TVILIGHT SMART
STREET LIGHTING
OBJECTS NETWORKS
ADDICTED TOASTER
Figure 14. Overview of the
6 categories of Connected
Objects

Market analysis - 33
1
#011231=#ff0000 - 2-12-2013
#011231=#FFFF00 - 3-12-2013
2
OBJECTS LINKED TO DIGITAL DATA
OBJECTS THAT PUBLISH DATA ON THE WEB
GOOGLE TALKING SHOE
OV-CHIPKART
DEVICES
PEOPLE
FITBIT AUREA
DATA
SMART CITIZEN
PLACES
OBJECTS
AMBIENT UMBRELLA
SKUBE
GOODNIGHT LAMP
LG-TINKQ
PHILIPS HUE
REMOTE CONTROLLED OBJECTS
INSTACUBE
LITTLE PRINTER
OBJECTS THAT PULL DATA FROM THE WEB
4
3

34 - TINK
2.2.1 - Objects linked to digital Data
#011231=#FFFF00 - 3-12-
Figure 15. OV-Chipcart
This category comprehends physical objects
that are linked to some kind of digital data.
Historically it is the first manifestation of
IoT products. In principle the category
comprehends all the object that are
connected a treaceble unique identifier.
The identification can be achieved through
unique ID numbers, barcodes or QRCodes.
The most seamless interaction, however,
is achieved through RFID tags that can be
hidden inside any object.
This category of product is very important
in the History of the Internet of Things.
When Kevin Ashton in 1999 invented the
term IoT, he was actually envisioning
a world where objects were uniquely
addressable and it would have been
possible for a computer to process those
object in the same way it processes data. 2
Object that are uniquely addressable via
RFID are not the only component of a
system based on RFID. Other components
(RFID scanner, computer, database etc.)
are necessary in order to connect objects
to data.
Linking atoms and bits is the first step in
order to extend products with information.
“Tale of Things” 14 is the name of a project
that makes use of RFID technology to
connect people’s memories to real world
objects; the memories are in form of video
and are recorded by the owner of the
products.
If we explain the project in this ways it is
hard to see the direction of the information
flow. But looking at the whole service we
notice that firstly, pieces of information
flow from a user to a server: when a new
object is added the story of the object
is recorded and saved. Then a link in a
database is created between the object and
the information. In this way when a new
user will inspect the object, the user will
be able to retrieve the information linked
to it. The information this time will flow
from the database to the user.
While in the previously discussed example,
objects are not able to produce information
by themselves; RFID technology can also
allow this kind of interaction. In the case
of the OV-Chipkard 15 (Figure 15), Every time
the card is scanned, the time and location
of the card –and its owner- is recorded in
a database. Information in this case is
flowing from the card to the dataset, but
within the same system information also
flows in the other direction since every
time the card is scanned, the device ask
the database how much credit is left on it.

Market analysis - 35
2.2.2 - Objects that publish data to the web
This category comprehends all products
that are able to directly connect to the
Internet and publish content.
More and more environments and objects
are getting equipped with sensors. This
allows us to keep track and read information
that was invisible before. The contents
published online are then accessed through
other media. Objects are able to directly
interact with social networks like twitter,
or log the data in dedicated database.
We can divide objects that are part of this
category in three sub-groups:
Sensors: the product is nothing more than
a bunch of sensors connected to some
electronic that post the sensor readings
online. It is the case of the Smart citizen
project 16 (Figure 16), a sensor board that
collects different types of environmental
data and publishes them on a website.
Objects that embed sensors: The products
already have a “non-digital” purpose but
are equipped with sensors in order to track
and monitor something related to the
interaction.
In most cases these types of objects offer
the user other touch points to visualize the
data. Fit-bit Aria 17 (Figure 16) is a digital
scale system able to identify different users
and record the measurement on-line, this
allows the user to keep track of progress
over time. The time scale adds another
dimension allowing the user to transform
the singular data into more valuable
information. The user might, for example,
discover a pattern related to the amount of
physical activity done in a certain period,
thus allowing him to keep track of the
effectiveness of his training.
Object that transform data in
information: This is the case of objects
that instead of publishing raw data online,
are able to make sense of it and transform
it into meaningful information. An example
of this kind of approach is the “Talking
Shoe” project by Google 18 (Figure 18),
where the data retrieved by the sensors are
used to determine what kind of activity the
user is doing. After the analysis the shoes
can talk to their user trough a speaker and
the user’s smartphone to motivate him in
his sporting activity.
Figure 16. Smart citizen board
Figure 17. Fit Bit Aria
Figure 18. Google talking shoe

36 - TINK
2.2.3 - Objects that pull data from the web
Figure 19. Skube (2012), A.
Nip, R van der Vleuten, M.
Borch, A. Spitz
Figure 20. Ambient Umbrella
(2007), Ambient devices
The category comprehends products that
use the Internet connection to retrieve
data and operate according to it.
Often the interaction with those products
is aimed at creating seamless connections
between users and Internet, moving away
the people from the classical browser.
This is achieved by embedding digital
information in to tangible products
Objects in this category can be physical
representation of social network, like
Instacube 20 and Skube 19 (Figure 19): A
digital frame, the first, which display
Instagram photos, and an audio player
connected to Spotify and Last FM.
In both case it is possible to access
the social network using a specialized
tool. Thus making the interaction more
contextual.
Some projects in the category can be
described as interfaces aimed at providing
access to digital contents in a more
meaningful and contextual way. This is the
case of the Ambient Umbrella 21 ,(Figure 20)
an Umbrella with Internet connection that
reads the weather forecast and informs
the user if it is necessary to go out with
it by changing the colour of a light on the
umbrella itself. The Umbrella is particularly
relevant because apart from displaying
data, again it goes beyond providing
just data to the user, it in fact proposes
decision for the user giving suggestions on
weather to go out with the umbrella.
Transforming data in to information is
what make the object “smarter”. While the
umbrella cannot operate autonomously and
can just propose decision, other objects
use the data to operate autonomously.
An example could be an irrigation sensor
that before watering the plants will also
check the weather forecast, If it discovers
that it is going to rain in the afternoon
it might take the decision to not watering
the plants
This kind of objects aimed at automation
and process optimization has been largely
used already in the industry. Lately the
as the cost of the electronic and software
is diminishing smart objects are being
developed also for end users especially in
the context of “smart home“.

Market analysis - 37
2.2.4 - remote controlled objects
Objects connected to the Internet can be
“remotely controlled”.
There is a big distinction between
objects that are controlled by a web or a
smartphone interface, and objects that are
remotely controlled by other objects.
The simplest example of a product that is
part of the first category is the Philips Hue
lamp 22 (Figure 21) : A programmable light
bulb with Wi-Fi connection. Through a
smartphone app the user is able to change
the colour of the light. Because this action
usually takes place when the user is in the
same place of the lamp, the smartphone
app doesn’t have to provide any feedback
to the user.
This doesn’t happen in the case of
remotely controlled objects that are in
other locations. The LG smart appliances
with THINQ 23 technology is a family of
interconnected house appliances that the
user can remotely monitor and control from
a web app. The monitoring feature implies
this time a two-way communication
between the device and the user.
Objects can also be controlled by other
objects, this is the case of the Goodnight
Lamp (Figure 22), a family of interconnected
lamps that let you share your presence and
availability to your loved ones easily and
in an ambient way 24 .
In this case a main lamp is connected to
other lamps that are remotely controlled
by the first one. When the main lamp
(controller) is turned off, the others do the
same.
Figure 21. Hue (2012), Philips
Figure 22. Good night lamp (2012),

38 - TINK
2.2.5 - Bidirectional communication devices
actuator
sensor
sensor
actuator
The good night lamp described previously
is somehow very close to this category of
products.
The category comprehends in fact devices
aimed at connecting people in different
places via tangible interfaces. Products
in this category are also referred to as
tele-presence products.
An example is Kissenger (Figure 24), a
system composed of two devices that
provides a way of transferring a kiss on the
distance 25 . It provides a physical interface
which enables kiss communication for
several applications facilitating intimate
human tele-presence with the real and
virtual worlds.
Figure 23. Kissinger (2011),
Lovotics
What sets this category apart from the
one discussed earlier is the possibility of
having a two-way communication between
the devices. Products in this category
are specular, the sensor on one device
are “directly” connected to actuators on
another device.

Market analysis - 39
2.2.6 - Objects Networks
This category of products is the least
explored in the IoT landscape, it
comprehends networks of many objects
which talk and communicate with each
other.
Networks of objects can be composed
of similar or different type of objects.
The connection between them can be
hierarchical or horizontal.
Network of object use the network to share
data between each other, they usually
don’t influence each other directly but is
the global behaviour of the network that
influence the single entity.
An example of this kind of product is the
TVilight system for smart lighting 26 (Figure
24): A networks of street light poles able
to dim the light when no one is present
on the street. The light poles communicate
with each other in order to provide the
required light level when someone is
passing by.
The poles have to share information
between each other: when the sensor on
one pole detects an approaching car it has
to notify the 10 poles next to it to turn on
their light as well.
Addicted toaster 27 (Figure 25) is
another good example of a network of
interconnected products.
Addicted Toasters are toasters that love to
be used, toasters with agency and desires,
toasters that will get jealous of other
toasters that are appreciated more.
The toaster communicate to each other to
know how their fellow Toasters are faring.
If a toaster thinks that it is not being used
enough, it will try to get itself transported
to someone else that makes more toast.
Figure 24. City Sense (2012),
TVilight
Figure 25. Addicted Toaster (2012),
Simone Rebaudengo

40 - TINK
2.3 Connected objects toolbox
Until now the topic of what kind of tool is
needed in order to sketch and prototype this
kind of products has not been discussed. In
order to have a clear overview of existing
tools, a market research was conducted .
The research focused on tools both
commercially available on the market and
on Kickstarter projects.
In figure 26 an overview of the different
tools analysed can be observed.
Three categories of tools have been
discovered, Software, Hardware, and
combination of the two.
The tools are placed on the graph according
to the category they are part of and the
level of technical skills required in to use
them.
Not all the tools can facilitate the
development of experiential prototype of
all 6 categories of connected objects. The
one that are easier to use, in fact, are most
of the time limited to the development
of interactions of a specific a category.
More advanced tool, on the other hand
can be used to prototype any kind of
communication model described, however
as those tools are more versatile they
Figure 26. Map of the tools for
Connected Objects.
HARDWARE
sensem
SOFTWARE
Smart Things
Ninja Sphere
Readymate
Twine
Wemo
HW+SW
Staple Connect
Nabaztag
Wemo Make
SKILLS RULER

Market analysis - 41
require more technical knowledge from the
user.
More information on each specific platform
can be found on the blog I used to
document the research phase of the project
http://connectedobjects.tumblr.com/ .
Arduino YUN
Spark
Pinocchio
Raspberry PI
Electric Imp
Intel Edison
e
IFTT
Maker Swarm
Ninja block
r

42 - TINK
2.4 Tools users
Figure 27. End User, Maker and developer:
3 target user of Connected
Object tools
The fact that different tools require
different levels of skill as shown in Figure
26 is also directly connected to the fact
that the different solutions are targeting
tree different user groups:
The End-user
End users might be interested in Connected
Object tools to simplify their life, keep in
touch with people and monitor things over
longer distances.
In terms of skill, end user don’t have
electronic or programming background,
they are however able to operate
smartphone apps and computers.
As already discussed in the chapter about
tools, end user products present a limited
amount of “openness”. Tools designed
for end users are most of the times a
combination of hardware and software. This
creates a uniform user experience, does

Market analysis - 43
not require the user to choose a specific
platform and limits the functionalities to
what is really needed.
In order to be simple to use, end user tools
usually perform one very specific task,
providing a very limited amount of options.
The Maker
Makers are interested in IoT tools that
allow them to bring their ideas to life.
They have some programming or electronic
experience, but in most of the cases they
start working on a project by looking at
tutorials online.
Makers look for versatile tools: usable in
different contexts and for multiple projects.
Since makers look for the easiest way to
implement their ideas, they prefer to hack
and modify tools rather than starting with
something from scratch.
The Developer
Prototyping software and hardware is part
of the developer’s profession.
Most of the time developers have
engineering backgrounds, therefore they
are either very capable in software or in
electronics.
Tools targeting developers make use of the
specific expertise developers have.
In the research for example several
boards targeting software developers were
identified. The Tessel Board, for instance,
is targeting web developers, it comes with
a set of sensors that can easily be snapped
on to the board to facilitate the electronic
development. Additionally the Tessel board
can be programmed in Javascript, a very
common web programming language.
Developers look for tools that are scalable,
efficient and stable. They have to feel in
control of the project, and even though
they might make use of third party
libraries, they are able to understand and
modify those if required.
While the categorization might seem very
strong, it is clear in the graph ... that there
is some overlap between tools for endusers,
makers and developers.
Makers in fact might be interested in
hacking a product designed for end-user
in order to accomplish their goals and
at the same time developers might use
maker tools to quickly produce and test a
prototypes.
The interaction designer
Defining the average skill level of
interaction designers is not easy.
A big debate is going on about how much
interaction designers need to know about
coding or electronics.
According to the study program followed,
some users might be more skilled with
programming and electronic and some
won’t. If I look at my fellow interaction
design student trained at TU Delft, I can
place most of them between makers and
end users, in fact some have good making
skills, but most of them do not.

44 - TINK
Figure 28. Exploded view of a bike,
from “Things came apart” (2013),
Todd McLellan
2.5 Technology
archetypes
New prototyping tools are produced
every day. Every new board and software
announced has some distinctive difference
from the others. However, several
characteristics are shared amongst them.
The different tools summarized in figure 26
have been deconstructed in terms of their
core features and several tool archetypes
were identified. The deconstruction
followed different criteria for the 3
different categories of hardware, software
and HW+SW.

Market analysis - 45
2.5.1 Hardware
A wide range of different electronic
prototyping boards are present on the
market, each of them comes with a
different set of specifications regarding:
• Connection capabilities (usb,
bluetooth, wifi, ethernet, zigbee,
etc.)
• Numbers of available input output
• I/O capabilities (i2c, PWM, ADC etc.)
• Programming language (C, javascript,
python, linux, MaxMsp etc.)
• Processing power
• Hack-ability 5 (does the board come
with a fixed set of extension sensors
or can you connect a wide range of
other electronic devices?)
An electronic platform is required whenever
an experiential prototype requires reading
value from the world and/or affecting it
trough sensors and/or actuators.
Although this category of archetypes
describes hardware platforms, it must be
specified that in most of the cases, in order
to define the behaviour of an electronic
board, the board has to be programmed.
The practice, also known as physical
computing 29 requires the user to acquire
knowledge on two quite different discipline
such as programming and electronics.
Some boards however are intended to
make the application of interactive objects
and environments more accessible. Thus
allowing interaction designers to use them.
Two main strategies are leading the
development of electronic prototyping
boards for interaction designers:
• The first one is providing the user
with an “easier” way to program the
board. In the case of Arduino 28 for
example it was decided to use an IDE
that is very minimal and similar to
processing with which Arduino also
shares the programming language.
Lego Mindstorm 30 instead can be
programmed via a graphical user
interface by connecting several
building blocks together (Figure 29).
• The second strategy is lowering
the barrier of the electronic
development 31 : Some platforms come
with pre-assembled modules that the
user can just plug in to the board
without worrying about resistors
capacitors or breadboard. Examples
of this are the tinker kit for Arduino
(Figure 30) and the Phidgets board 32 .
Because my focus for this project is
analysing tools aimed at the development
of experiential prototypes of connected
products, the different boards were
categorized according to the strategy
used to connect them to the Internet, the
different connection layouts respond to
the different needs of every project.
Figure 29. Lego mindstorm
programming interface.
Figure 30. Arduino Tinkerkit.

46 - TINK
Figure 31. Classification of
wireless technology according
to transmission range and data
rate
EVERY BOARD IS DIRECTLY CONNECTED
TO THE INTERNET
The configuration is used when a single
product needs to connect to the Internet
in order to communicate to the cloud or to
other devices.
Wi-Fi, Ethernet and GPRS are the main
technologies able to provide the board
with a direct Internet connection.
Ethernet connection is the easiest way to
connect a device to the Internet, most of
the time no configuration is needed, thus
allowing the product to be installed easily.
Since in most of the environments it is
not possible to connect a device directly
to the home router with a cable, products
with WiFi connectivity are becoming more
popular.
This kind of wireless connection,
however does not significantly improve
the portability of the object due to the
relatively short range (Figure 31). Projects
equipped with WiFi are in fact most likely
limited to the domestic environment.
3g and GSM connection on the other hand
provides the maximum level of portability.
Products equipped with this kind of wireless
modules can be connected to the Internet
from areas where no other connection is
available and in contexts where the device
is moving. (e.g. In drones, on cars, for
shipment tracking etc.)
While connecting a product directly to
the Internet presents several advantages,
it also has some downsides related to
the relatively high price and the big
power consumption. Thus making this
connection layout not optimal for projects
comprehending large networks of sensors
close to each other, or for wearable and
portable devices.

Market analysis - 47
SEVERAL NODES CONNECTED TO A
GATEWAY
This kind of configuration is used when
a large number of objects have to be
connected together and/or to the Internet
and are relatively close to each other.
In this case Radio connections (of which
the actual most implemented standard
is Zigbee) can be used to connect the
different nodes together. If an Internet
connection is then needed, few nodes can
be equipped with an Internet connection
and serve as gateways for the entire
system.
The layout presents some advantages:
the node-to-node radio communication
is a cheap technology, it can provide a
long-range connection, and it requires a
small amount of energy to function, thus
allowing this product to operate for a long
time on batteries.
The main disadvantage is related to the
fact that two communication protocols
have to be implemented in order to have
the nodes able to talk to each other and to
the Internet.
THE DEVICE USES THE INTERNET
CONNECTION OF AN OTHER DEVICE
This kind of configuration is mainly used
for products that have to be small, cheap,
low power, or just need to communicate
over a short distance on local networks.
This is the case of all the wearable sensors
that are connected to smartphones (e.g.
nike Fuelband 33 ). The smartphone is able
to analyse the data provided by the sensor
and serves as a bridge between the object
and the Internet.
Bluetooth low energy (BLE) is going to be
the main technology that will make use of
this kind of layout 34 .
While the technology is very promising
due to it’s low price and the low power
consumption, the development of a
product that uses this kind of connection
layout is relatively difficult since it is
required to program both the electronics
and the smartphone app.

48 - TINK
Software
In Order to develop standalone, “nonconnected
Object”, just the software for
the board needs to be developed. However,
when developing interactive application
for connected objects, all the other
devices, websites, and other services that
are connected to the board need to be
programmed as well. Most of the time the
programming is done through coding and
usually different programming languages
are used in different contexts (php and/
or Javascritp for web, iOS or android for
devices, c for Arduino etc…).
While, as discussed already, very few
Interaction designers have programming
knowledge, in most of the time this
knowledge doesn’t go much further then
some Arduino, Processing or Max MSP.
For this reason, several tools have been
developed in order to lower the barrier of
coding of connected products and allow
people with no or very little programming
skills to be able to configure and automate
some behaviors.
Several common functionalities have been
discovered during the analysis on software
tools. We will refer to those as software
archetypes. Those archetypes are not
related to a specific tool, in fact tools in
this category embed most of the time more
than one archetype.
THE DATA LOGGER
This kind of software allows the collection
of data measured by the object. Examples
of this kind of application are Patchube 35
and Xively 36 .
Some library is usually provided in order to
interface the hardware to the website that
collects data.
Usually the software provides standardized
modules to visualize different types of
data, however the data can also be logged
on a spreadsheet and then visualized via
external software.

Market analysis - 49
THE EVENTS LINKER
Event linkers are a type of software which
facilitate the programming of simple event
based behaviors:
Events can be triggered by sensors (e.g.
The temperature dropped) or by digital
events (e.g. Receive an email, like on
Facebook etc.). The triggered actions can
be either digital (e.g. Send an email) or
physical (e.g. Turn on the light).
Some linking software allow the linking
of discrete values (e.g. Adjust the level of
the light according to the loudness of the
room).
Most of the time the mapping of a trigger
to an action doesn’t allow for complex
condition (If this and that…)
THE SDK
A software development kit (SDK or
“devkit”) is typically a set of software
development tools that allows for the
creation of applications for a certain
software package, software framework,
hardware platform, computer system, video
game console, operating system, or similar
development platform.
It may be something as simple as the
implementation of one or multiple
application programming interfaces (API)
in the form of some libraries to interface
to a particular programming language
or include sophisticated hardware to
communicate with a certain embedded
system.
An example of a SDK is Temboo 37 : a set
of API that allows you to interface your
hardware platform with more than 100
different third party web services. Through
its web interface Temboo goes beyond
providing just a software library, it is also
able to generate pieces of code ready to be
copy-pasted.

50 - TINK
Software + Hardware
These kinds of solutions are most of the
time a combination of one of the previously
listed hardware and software archetypes
developed to target mainly end-users or
makers.
THE SENSOR BOX
The sensor box is an electronic board
that includes one or more sensors; it is
connected directly or indirectly to the
Internet where the data is stored.
Often it comes together with a piece of
software that is used to configure the
board, keep track, and visualize the logged
data. The software might also allow the
user to perform some linking action (e.g.
If the temperature rises over 40° send me
an email.)

Market analysis - 51
THE REMOTELY CONTROLLED OBJECT
This category comprehends all the devices
that can be remotely controlled to switch
home appliances on or off, open doors,
change the colour of the lights etc.
They come with a piece of software that
enables the user to remotely control them.
Products in this category are often
accessible via open source API, thus
making it easy for makers and designers to
include them in their projects.
Moreover those products can be connected
to other platforms (see the smart home
gateway category).
Philips hue 22 or the Belkin WeMo switch 38
are part of this category.
THE SMART HOME GATEWAY
A smart home gateway allows several
devices to be connected to the Internet.
The gateway implements several
communication methods and protocols,
thus allowing it to connect to devices
manufactured by different companies that
are implementing different communication
protocols. Its role is to create connections
between remotely controlled objects,
sensor boxes and devices.
Through a configuration app several
profiles can be configured, the house can
be monitored and special events can be
linked together.
An important parameter when deciding to
buy such a platform is related to how many
third party devices it can connect to.
Some smart gateways are open source and
based on open hardware, this allows the
user to modify its behaviour adding more
nodes and sensors to the system.

52 - TINK
Design directions
From the research on IoT products, it
emerged that category 6 (networks of
interconnected objects) is the least
explored: While the topic of creating an
infrastructure to connect products one
to the other in order to leverage the
full potential of IoT application is very
relevant within the IoT community 39 , very
few project, between the one analysed,
go in the direction of creating network of
interconnected objects.
Several reasons can be discovered behind
this:
• The level of complexity of this kind of
system is quite high.
• No design tools have been designed
to sketch this type of products.
• Prototyping networks of objects can
be quite expensive in terms of money
and time since multiple objects have
to be prototyped in order for the
network behaviour to appear.
My project will try to address those
problems; The tool I’m going to design
will therefore assist designers building
experiential prototype of networks of
interconnected products.
This doesn’t mean that the tool won’t be
used for the development of IoT products
from other categories. Networks of objects
in fact can embed all the communication
flows characterising of the other categories.
The tool will be a software solution
that will assist interaction designers
in developing experiential prototype of
connected objects.
The software will support the development
of physical interactive prototyping, and it
will work in combination with a hardware
platform.
The chosen board will have a direct
connection to the Internet. This
connection layout might not be the most
optimal one for every project, especially
considering the higher costs of equipping
a prototyping board with this kind of
connection. However this connection
layout will provide enough flexibility to
develop all kind of experiential prototype
of connected object.

Market analysis - 53

CHAPTER 3
User research
USER RESEARCH was conducted to understand how designers think
and design complex systems.
During the sessions with users, participants were asked to design and
represent a system of connected objects.
In this chapter, the setup of the research is explained and the findings
are discussed. From the results the PROGRAM OF REQUIRE-
MENTS is formulated and is described in this chapter’s conclusion.

56 - TINK
After having analyzed different categories
of connected objects and the tools that
can be used to build experiential prototype
of those a research was conducted in order
to acquire knowledge about the target
users of the design.
3.1 Research questions
The research was aimed at answering the
following research questions:
-What’s the level of knowledge that interaction designers have regarding
IoT objects?
-How interaction designers design complex systems?
-How interaction designers represent complex system?
-How can we help designers evaluate all the possibilities offered by IoT
products?
-The research was also partially aimed at validating the relevance of
using the communication model designed in chapter two as a tool to give
structure to the representation of complex systems of connected objects.

User research - 57
3.2 Research setup
The research was structured as a generative
session organized in 7 phases alternating
idea generation with synthesis phases.
A facilitator had the role of explaining
the different exercises and assisting the
participants when they where in doubt or
stuck. The research involved 4 sessions and
2 participants took part in every session.
Most of the participants were interaction
design students at the end of their master,
one of them was a student of computer
science at the end of his master. The
participants were chosen based on different
levels of technological skills:
• 2 participants never had programming
experience;
• 2 had a very little, never done a project
without assistance or following a step
by step tutorial;
• 3 had Arduino programming
experience; they were able to program
simple software autonomously
• 1 was a software developer
In a step-by-step approach the participant
had to, first, design a complex system and
then make a representation of it.
Markers and different exercise sheets for
the different phases of the session were
given to the participants. A set of card
was also designed to help the participants
generate idea on different topics.
Phase 1 - Imagine that a specific
object is connected to the Internet
what will it do?
The session started by asking the
participants to brainstorm on the possible
design that could arise from connecting a
simple object to the internet (Figure 32).
Different objects were used as starting
points in different sessions (coffee mug,
coffee machine and a plant).
Phase 2- summarize your concept
The participants were then asked to choose
one idea from the brainstorm session and
summarize it either graphically or in words.
Figure 32. A result from phase
1 (Imagine a coffee maker
connected to the Internet,
What will it do?)

58 - TINK
Phase 3- Imagine if…
Figure 33. Usahe of the set of
cards to expand the original
idea
In phase three the goal was to expand the
concept just created. The set of cards was
introduced in this phase. According to the
concept developed in the previous phase,
different cards where provided by the
facilitator.
The cards were supposed to encourage the
participants to expand their idea with new
features: On every card a statement was
provided (e.g. Imagine if the plants could
post on social network; imagine if the
plant could be connected to an other plant
etc.) (Figure 33).
Every statement was related to a
technological feature or possibility typical
of connected objects extracted from the
analysis of the IoT projects.
If a feature was already been implemented
in the design, the facilitator had the
possibility of skipping the card.
4- Summarize the new idea
At this stage an ulterior synthesis phase
was required; The participants where asked
to combine all the new features in a new
concept. The participants could chose
to exclude some features if they were
considering them unnecessary for their
design.
Figure 34. Representation of
the interactions between the
entities inside the communication
model

User research - 59
Phase 5- Sketch the communication
flow between the different touch
points
In this phase, the communication model
designed in chapter 2 was used*; a
printout of the communication model
without the connecting arrows was given
to the participants. A short explanation
of how the model was meant to work was
provided. To the participants was asked to
deconstruct the envisioned interaction in
different actions, for every action identified
it was required to draw an arrow from the
entity that was performing the action
towards the receiver of it (Figure 34).
Phase 6- Draw a system diagram of
the system
The participants had to draw a system
diagram of the designed system (Figure
35). The participants where asked to
visualize the system as they would have
done in the case they had ask a developer
to program it.
Phase 7- Comments and remarks
At the end of the session a short interview
with the participants about the exercises
was done.
Figure 35. Sketch of the system
diagram: The cloud become a
big brain that monitors and
control the behaviour of the
system.
* The communication model presented in chapter 2 was not comprehensive of the places entity, this one was added
consequently to some observation gained during the research.

60 - TINK
Research results
The recording of the sessions were
analysed; the most important findings are
here presented:
Interaction designers’ knowledge
on the possibilities offered by IoT
products:
All the participants demonstrate to have a
very good knowledge about the possibilities
that connecting product to the Internet
could bring to the design practice. In the
initial brainstorming phases in fact already
several topics came out.
Participants with more technical skills
produced less ideas then participants with
less technical skills, we might reconnect
this to the fact that technical minds
tend to focus too much on the technical
feasibility of their idea, this results in a
limitation in the idea generation phase.
The use of inspirational card to
develop new ideas
The set of card was valued as a very
important tool to generate new ideas and
have a good overview of all the technical
possibilities brought by the possibility of
connecting object to the Internet.
Some participants stated that the cards
were very useful since they were promoting
reflection on single aspect of the
interaction at the time.
While the cards where very good in trying
to inspire new ideas on a technological
level, there were no cards tackling a user
centred design perspective. These made
the users experience the set of cards more
as technology-driven than a design driven
tool.
The communication model as a tool
to structure the system
The participants to the test experienced
the communication model very positively.
The tool helped them to deconstruct their
concepts in small actions.
The strict division between the facet of the
interaction proposed by the communication
model, forced the participants to think in
terms of minimal pieces of interaction and
helped them deconstruct their concept in a
very efficient way.
The cyclical structure of the model, allowed
the user to decide where to start filling it
in:
• A first approach used was to start
by listing the data needed by
the system. Connections were then
created according to which actor in
the scheme was producing and using
the data.
• A second approach was to focus
on one facet of interaction at the
time, for instances on the interaction
between the object and the user,
once that section of the graph was
completed, the participants focused
on another section. The connection
between consecutive actions
happening in different sections was

User research - 61
analysed at the end.
• A third approach used, was to
consider an action as a consequent
set of events happening on different
layers. This approach requires a
very good understanding of how the
system is working and therefore was
mostly used by the participant with
software engineering background.
While most of the session started with
different approaches, at the end of the
exercise, in all the session was observed
a switch towards the third approach of
filling the scheme. This can be interpreted
as a consequence of the fact that the
scheme, after a short learning time is
easily understood and therefore is used in
a fluent way.
At first glance some participants found
the model confusing: the openness of
the model in fact does not suggest any
procedure to fill it in nor a clear starting
point.
Some other limitation of the model were
discovered:
• In a complex system of connected
object multiple entities can play a
role, Expanding the diagram with
multiple users, objects and devices
might be required in order to have a
clear representation of the system,
however, this might result in a
complicated tangle of arrows.
• If an object performs an action
towards the environment, this is not
considered by the diagram.**
In the section of the model between object
and data, it is interesting to notice that
while the data being sent to the cloud
are always simple data, (a number, a
location etc.. ) the data that the object
or a device retrieve from the cloud are
most of the times complex information
(preferences, behaviours etc…) derived
from data recorded over time and/or by the
collections of data produced by different
entities.
Designing the system diagram
The assignment of designing a system
diagram was voluntarily vague; no
indication on how a system map is
supposed to look like was given in order to
not influence the participants. Due to this
reason four completely different system
diagram were produced.
Anna and Claudia designed the system map
as a series of actions that are happening
one after the other. The system diagram
they designed represent how different
actions are happening in a chronological
order.
This kind of system is therefore very close
to a representation of the concept in the
form of a storyboard.
In the short interview done after the test
it was stated by the participants that
** The communication model presented in chapter 2 was modified including the places entity in order to solve
this issue.

62 - TINK
a step was missing: The detailing of the
interaction in the form of a scenario was
highly valued.
Anna Stated that telling the story helps her
“taking the system out of her minds”.
Luke and Fabian struggled with the
system map:
They first tried to represent the system in
the form of a state machine; they determine
the basic states that their object could
assume and then tried to relate those state
with the input (data and sensor) the object
was collecting.
Not confident in their result they quickly
got stuck.
Gyan and Jenn started by envisioning
the object as an entity that has input and
output. The other elements of their system
“the cloud” was represented as a big brain.
Arrows were used to connect the object to
the cloud. The big brain was envisioned as
an entity able to collect data from every
object connected to the system, process
the information and control the objects
behaviours.
Their system was also connected to
Facebook, this was represented outside the
brain as a separate block.
Then he used arrows to connect all those
entities, every arrows was representative
of the information flowing between the
different actors.
Due to the fact that the concept was not
very clear in his mind when he started
drawing the system map, a lot of questions
about the behaviour of the system raised.
This supports the thesis that drawing a
system diagram helps designer thinks at all
the possible interaction that might occur.
Fabio represented the system with two
different sketches:
He first draw the system architecture
representing in which way different
“entities” are connected to each other
(In his map the entities are all physical
entities: e.g the cloud is composed of a
server and a database); The second sketch
was instead a timeline representing how
request and responses are flowing between
the different parties involved in the
system.
In this way he divided the representation of
“the information” from the representation
of the entities part of the system.
Tommie’s diagram resulted in a complicate
tangle of lines: He tried to represent
multiple objects in his map, he divided the
“cloud” in to a server and a database, and
did an attempt to structure the DB setup.

User research - 63
3.4 Discussion
The result of the research provides a lot of
insights that will be used as a basis for the
ideation phase.
INSPIRATION
The set of cards can be helpful in an initial
brainstorm, especially in situations where
the technological skills of the participants
is not very high. The set of cards should
however be expanded or integrated with
other tools in order to take into account
both the technological aspect of the
system but also a user centred perspective.
ZOOM IN AND OUT
When designing a complex system, it is very
important to maintain a clear overview of
how the system is supposed to behave, but
also have the possibility to zoom in the
detail of the interaction.
DECONSTRUCT
Deconstruct the system in smaller block is
an engineering technique to analyse and
solve problems. Interaction designers are
not used to this practice but if assisted
with tools, they can easily experience
the advantages of this problem solving
technique.
OPENNESS
As already discussed, a high level of
openness requires more skills from the
users. The exercise of filling in the
communication model was more successful
then the one about representing the
system diagram. This was probably due
to the fact that in the last exercise the
participants had to start from a blank page
while in the previous one the structure of
the communication model was provided.
The Communication model was at the same
time open, in the sense that user could
start filling it in the order they preferred,
but also fixed since it was already
proposing a way to schematize the system
and suggesting ways of deconstructing the
interaction in smaller actions.
ANALYSING DATA
Analysing data and making sense of them
was defined as one of the very challenging
activities.
In the design of the system diagram, often
the representation of how the data is
transformed into higher-level information
was not considered. In most of the cases
it was assumed that an entity - somewhere
in the cloud - was able to analyse data and
make sense of those.
In order to help designer to make sense
of the data collected, it can be helpful
to provide a meaningful visualization of
those.
LEVELS OF ABSTRACTION
Interaction designers design complex
system on a higher level of abstraction
than programmers and engineers are use to
do. The tool should facilitate this process
of abstraction.

64 - TINK
3.5 Program of requirements
The observation from the test leads to the
formulation of a program of requirement
for the platform.
1) Platform goal
1.1 The software should allow the
development of experiential prototype of
connected objects.
1.2 While it should mainly target the
needs of the development of networks of
connected object (category 6), this will
result in allowing the construction of
experiential prototype that are part of any
other category presented in chapter 2.
1.3 The software will embed the sketchy
quality discussed in chapter one.
1.4 It should provides tool for storing
visualizing, analysing and understanding
data
2) Target users
2.1 The software is meant to target
interaction designers.
2.2 While the full potentiality of the
software will be available to users with
a minimum level of understanding of
Arduino code, the platform should be
understandable by Interaction designers
with different level of coding skills.
3) Versatility
3.1 The software should assist the
development of experiential prototype
along the all design process. It should allow
users to explore different possibilities in
the beginning of the design process, but
also developing more detailed experiential
prototypes for testing purposes.
3.2 The platform won’t force the user in
a strict work-flow, but will allow different
users do define their own flow.
4) Openness and level of visibility
The platform will provide different levels of
accessibility:
4.1 It will help designers keep the overview
of the system and at the same time allow
them to have access to the details of the
interaction.
4.2 The software should help designers
deconstruct the envisioned interaction in
basic construction blocks. In doing so, the
distinction between the different facet of
the interaction should be promoted.
4.3 The software will be open source and
hack-able. A set of API should be provided
allowing expert users to have full control
over the platform and enable them to
integrate the advantages brought by the
software in their usual work-flow.

4.4 Moreover, it should be possible to
operate the software and modify behaviours
remotely, and when electronic boards are
not connected
5) Usability
5.1 When programming in hardware, it
is often difficult to understand whether
the code is performing as expected, the
platform should therefore provide the users
with real time feedbacks about the state of
the hardware.
5.2 The interface should be clear and
understandable for a better user experience.

CHAPTER 4
Final design
Guided by the program of requirements, an ideation phase lead
to the DESIGN OF TINK, a web platform that makes it easy to
connect products to one another.
In this chapter, the 3 MAIN COMPONENTS of the platform are
presented together with an analysis of the TECHNOLOGY envisioned
for the implementation of the design.

68 - TINK
4.1 Sketching TINK
Following the program of requirement
an ideation phase started. Several ideas
where produced based on the insights
gained trough the user research and the
market analysis; the ideas however felt very
connected to each other, as if they where
just different features of a bigger platform.
As soon as I started drawing pieces of
the interface I started connecting the
different ideas together. The sketching
helped me taking out the ideas from my
mind, iteratively reflect on those and make
modification to the initial concept.
This ideation process resulted in the
design of TINK: a web platform that
connects products with one another via the
Internet. Think builds upon the program of
requirements laid out in previous chapters
of this report offering designers a complete
Internet of Things (IOT) development
environment to sketch experiential
prototype of connected objects. TINK
is a user-friendly, visual, collaborative,
open-source tool for designers to build
connected interactions among objects.
User-Friendly
TINK targets interaction designers with
minimal Arduino experience who are able
to read and understand at least some
Arduino code.
This visual platform has a low barrier to
learning and its full functionality is easily
discoverable through use.
Visual
The interface hides most of the complexity
of the system, allowing users with different
skill sets to explore it, and learn the
different components of the platform.
TINK provides users with visual building
blocks to create functionality without
requiring any code to be written. Users
more comfortable in writing code can do
so within TINK and open, modify, or create
new building blocks to share with the
community.
TINK is composed of 2 main components:
one for editing the system and one for
monitoring it.
• The edit view combines system
diagram sketching environment with
a building block library and an code
editor
• The monitor view combines a map
displaying the locations of the
entities and graphs visualizing data
recorded by the entities.
Collaborative
This web platform allows different users
will be able to access, modify, and monitor
the project remotely and simultaneously
Open Source
As an open source tool, similar to
Wordpress and other content management
systems (CMS), it will be possible to use a
central version of the system, or install a

Final design - 69
private copy on a private server.
Figure 36. Sketches of TINK’s wireframe

70 - TINK
4.2 PROJECT VIEW
In order to be able to access the platform,
users have to create a TINK account.
Accounts can be connected to Google and
Facebook and other third party providers to
benefit from 3 main points:
• Data related to the third part
services can be used to set the initial
information needed to integrate third
parties services into the project.
• Connecting the account with Google
or Facebook allows users to import an
address book which can then be useful
to share the project with friend and
colleagues.
• The login to the platform can be
smoother as it is not needed to sign up
with a new user-name and password.
Users have the possibility to create and
store projects online. For every project it
is possible to sketch an individual system
diagram and access the monitor view.
Data will be logged/recorded continuously,
even if the user is offline and they will be
visible once the user logs.
Sharing
Visualize data
To user who is not in charge of the
prototyping might be given permission to
just visualize the data.
This user might use the data observed
to verify the design or write reports. The
permission to visualize the data can also
be given to stakeholders or clients so
that they can start gaining insight on the
project while a research is being conducted.
Modify System diagram
The research showed that although not all
interaction designers are able to program
an Arduino, most of them are capable to
design a system diagram. Users granted
with this permission will have the ability
to sketch and modify the system diagram.
Modify code
Programmers will be able to use the system
diagram as sketched by the designer and
fill in the code needed to have everything
working. The user granted with this
permission will have full access of the
entire platform.
Since most of the time design projects
are carried out in groups, a project can be
shared among multiple users. According
to the roles and level of expertise of
the different group members, different
permissions can be given to the different
users.

Final design - 71
Monitor
Edit
Ciao
Lorenzo
NAME:
Connected Coffees
SHARING:
Federico
Gyan
Ciao
Lorenzo
Luke
Your projects:
Wink
Connected mugs
Connected plants
Create a new one

4.3 SYSTEM VIEW
The system view is the core component
of the tool. It was inspired by how the
participants of the research drew system
diagrams of complex systems.
In the system diagrams every entity taking
part in the system is drawn. The entity’s
behavior is defined by the building blocks
attached to it.
Three kind of building blocks were designed:
Data to track, Triggers and Actions.
Lines are used to connect building blocks
together, and are representatives of
messages being exchanged by the entities.
ADD NEW...
CONNECTED OBJECT
A device connected to the Internet
CONNECTED OBJECT
Coffee Machine
ID studiolab_coffe_001
LOCATION 52.001883 - 4.369763
Clone
Data To Track
Coffe made
Triggers
New coffee
Actions
Deploy
Coffee Machine
New coffe
Monitor
Edit the full code
Edit
Alarm
Boolean Action
Turn on siren
115.4
Ciao
Lorenzo
Set siren speed
Entities settings
Settings for each entity are defined in
a setting panel that can be opened by
clicking on the gear next to the name.
For the different type of entities different
settings will need to be filled in.
For instance while the connected Object
will require information about location and
an unique ID. Web services are going to
require information on the user account
and eventual API key that have to be used.
WEBSERVICE
An external web service (Google, Facebook, twitter, etc...)
DATA ANALIST
It knows everything about the data you are recording,
it can be used to analyze the data recoderd from the objects
Cloning Entities
System entities
Four different types of entities are
identified: Connected Objects, Web
Services, Data Analyst and Devices.
While Connected Objects and Devices were
directly derived from the communication
model described in chapter 2, the data
element, represented by a cloud in the
system diagram, is split into two new
entities (web services and devices). Data
elments are also integrated in every entity
as the possibility to store data related to
any entity. (see image ..)
PLACES
PEOPLE
DEVICE
You can use it to remotely control the system from an
external device
OBJECTS
DEVICES
DATA
CONNECTED
OBJECT
TINK enables the connection
of physical objects to the
internet. Those object will
then be able to trigger
and be triggered by other
entities, either other
physical or digital.
In order to be functional
every Connected Object has
to be powered by a micro
controller. At the moment
Tink supports Arduino YUN,
but it will be possible to
extend the tool to other
Arduino compatible boards.
WEB SERVICE
TINK connects objects and
users together, not only
trough a physical interfaces,
but also trough the digital
online sphere. The web
service entity allows to
listen to events happening
on social networks or other
web services providers (e.g.
counting like on FB), or
perform actions (e.g upload a
picture to Dropbox).
DATA
ANALYST
TINK provides functionalities
to track, visualize and analyse
data. Data can be produced
by connected objects and by
other kinds of entities. The
Data Analyst has the ability
to inquire the database
where all the data related
to the project is stored and
produced derived.
This entity is helpful when
it is necessary to analyse
data coming from multiple
entities. (e.g obtaining
the average value of data
recorded by multiple devices).
DEVICE
Through Think objects can
be monitored and controlled
via different devices. This
entity facilitate the building
of simple user interfaces that
can be used to interact with
the the system (e.g visualize
data on a smartphone,
remotely control a connected
object etc.)
Often connected objects taking part to a
network are just clones one of the other
and are supposed to behave in the exact
same way.
The “clone” feature allows to create copy of
the same entity, the resulted cloned entity
will behave in the same exact way of the
original one since it will preserve the same
building blocks, however different settings
will have to be specified, in order to make
the uniquely addressable.
Cloned object will be represented in the
system diagram in a group with the icons
partially overlapping each other, this will
reduce the eventual tangle of lines that
could result from having too many entities
connected to each other on the system
diagram
Data to Track

Building blocks
Data To Track triggers Actions
Building block library Code editor Deploy
The behaviour of every entity is identified
by tree different building blocks:
The colour used in the design of the
building blocks helps distinguish the type:
blue for Data to Track, orange for Triggers
and yellow for Actions.
The shape of the right and left side of
the building block represent the kind of
messages that the building block uses as
input/output.
Nothing
Boolean
Int
Floats
Strings
The messages that can be sent between the
blocks have to be either boolean, string,
int or floats.
If the blocks uses messages, the value of
the message will be displayed inside the
shape, attached either on the right or on
the left of the building block.
ciao
Data To Track
Integer trigger 110
String action
115.4
String trigger
Connections
Float action
Boolean trigger
ciao
115.4
110
Connections can be made by dragging the
coloured outlet of a building block towards
the coloured inlet of an other building
blocks. The type of the outlet of the first
has to match the inlet of the second.
While the dragging is performed, a line
will be pulled between the mouse and
the starting building block. The shape of
the connectors helps visualizing where a
certain message can be sent and therefore
which building block can be connected
together.
Entities are able to
collect data. The data to
track building block allow
users to record events
and data coming from
the entities. The data
recorded will be then
visualized in the monitor
view. According to the
type of data recorded,
this will have different
visualization styles in the
monitor view.
According to the entity
that is recording data,
the data recorded might
be related to either a
physical data sensed by
a connected object (e.g
data sensed by a sensor
embedded in a connected
object) or a digital event
recorded by a virtual
entity (e.g. how many
like a picture got on
Facebook, the average
value of the sensor read
among multiple entities
etc.).
Every entity can listen for
events, and fire an action
accordingly. Triggers
are the blocks used to
listen to events; Triggers
are visible in the system
diagram where they can
be connected to Actions
building blocks. either
from the same or different
entities.
Triggers don’t accept any
kind of input messages,
but in order to be
attached to an action
they have at least to send
out a boolean message.
Every time a Data to Track
building block is created
a trigger related to that
data is automatically
generated. The user is
allowed to use it, delete
it or modify it.
Again, according to the
type of entity, triggers
might be related to
physical events or digital
one according to the
type of entity they are
connected t0.
When a trigger connected
to an action sends out
a new value, the action
connected to the trigger
will be performed.
Actions have to accepts
(at least) a boolean
message as input, and
are able to send out
messages as output.
Again, according to the
type of entity, triggers
might be related to
physical events or digital
one.
Add a new action to Coffe machine
Initialize the global variable you will need here
int relayPin = D6;
Initialize the variable you will need here
pinMode (relayPin , OUTPUT);
Write the Check_Coffe_Made function
String newAction ( float val){
}
Featured actions
Boolean
switch digital
Action
Pin
Boolean
Change neopixel
Action
color
My actions
ring bell
Turn the table
Or start from scratch
new Action
Boolean
New Action
Action
String trigger
A new building block can be added to the
entity by clicking the appropriate plus
button.
Once the button is pressed a popup panel
is shown in the foreground on top of the
system diagram; The popup gives the
user the possibility to choose between
predefined building blocks or to create a
new one from scratch.
The user also has the possibility to save
customized building blocks in a personal
library in order to be able to reuse them in
other future projects.
Update LCD text
LCD
Search in the library
Boolean Action
turn servo motor
Because the technological nature of the
different entities is quite diverse different
programming languages are going to be
needed in order to define the behaviours of
the different entities.
It was decided to focus just on connected
object entities for the scope of this project,
some recommendation on how to configure
the other entities will be provided in the
recommendation section.
The connected Object Building block
is programmed using the Arduino
programming language (C).
The coding of the block presents a similar
structure to the way Arduino code is
structured, the editor presents in fact
three distinctive areas to fill in with code
as listed below:
•Firstly the global variables that is needed
in the rest of the snippet has to be defined.
•Secondly the code that will have to go in
the void setup() function of the Arduino
code has to be defined.
•The last area is where the behaviour of the
building block is specified. The user has to
fill in this block by writing a function. The
skeleton of the function will be pre-filled
by the system. The user will have to define
what kind of message will the block sends
out as output, and what kind of values the
function requires as input.
servo float newAction ( String val){
String action
115.4
Once the code is created it needs to be
uploaded to the boards. When the deploy
button is pressed Arduino code will be
generated and uploaded on to the specific
board. If clones of that entity are present
on the system diagram they will be updated
as well.
When the code of a building block gets
modified the deploy button will be
highlighted reminding the user that he
needs to deploy the code to the hardware
in order to be able to see the modification.
The little downward pointing arrow can
be used to access advanced features such
as visualizing or downloading the code in
order to modify it in a different IDE.

74 - TINK
Draw the system diagram
ADD ENTITY
CHOOSE THE TYPE
GIVE A NAME TO THE ENTITY
UPLOAD A PICTURE
Entity are added by clicking the
plus button on top left corner.
From a side panel it is possible to
choose the type of entity.
Double-click on the entity name
makes it editable.
Dragging an image on the entity’s
will replace the default one.
ADD BUILDING BLOCK
CHOOSE FROM THE LIBRARY
CHANGE BUILDING BLOCK NAME
MODIFY CODE
Building blocks are added to the
entity by clicking the appropriate +
button in the side bar
SET CONNECTED OBJECT ID
It is possible to choose a Building
block from the Building Block
Library
DEPLOY THE CODE
Double-click on the trigger name
makes it editable.
DRAG CONNECTIONS
The code editor comes pre-filled
with basic code that has to be
modified according to the electronic
configuration
Every entity needs a unique ID,
configurable by clicking the gear on
the right of the entity name on the
side panel
Once the code is modified the
deploy button needs to be pressed
to upload the code on the hardware
Connections are created by
dragging the right or left sides of
the building block.

Final design - 75
Visual feedback
HOVERING A CONNECTION
HOVERING A BUILDING BLOCK
By Hoovering with the mouse
a connection, the entity and
building blocks connected to it are
highlighted.
A (x) button appears that can be
used to delete the connection
By Hoovering with the mouse a
building block, the entity and
building blocks connected to it are
highlighted
Testing
ENTITY IS OFFLINE
BUILDING BLOCK IS EXECUTED
MANUALLY TRIGGER ACTIONS
RECEIVING MESSAGES
When entities are not connected
are going they appear desaturated
in the system diagram.
When a building block is executed
and produces an output message, it
will shortly blink.
Actions can be manually triggered
by clicking on the left inlet.
When messages are exchanged
between the entities are going to
be visible in the system diagram
inside the building block.

4.4 THE MONITOR
VIEW
76 - TINK
studiolab-coffe
Coffee made
SUM every 5 min
The monitor view allows the user to
visualize the data recorded by the
objects, seeing the location of the
different entities and control that the
system is working as expected.
The monitor view is divided in two
parts, on the left the data recorded by
every entity are visualized while on the
right a map shows the location of the
different objects
8:00 8:20 8:40 9:00 9:20 9:40 10:00 10:20 10:40 11:00 11:20 11:40 12:00 12:20
1 apr 2013 from 8:00 to 12:20
THE MAP VIEW
The connected objects that have been
added to the system diagram can be
dragged to the map, in a specific position.
The map offers a spacial overview on how
the entities are distributed.
The map provides also the user with live
feedback oh how the system is behaving.
From the map it is possible to check if the
entities are connected and functioning.
Moreover every time an entity performs
an action, a pop-up will appear on top of
the entity with the name of the trigger or
action performed.
other and knowing what they are doing
gives the user the ability to observe
collective network behaviours emerging
from the capability the entity have to
communicate to each other.
When the user clicks on a connected
object, the data related to it are visualized
on the left side of the screen.
DATA VISUALIZATION
For each “data to track” connected to an
entity a data visualization is made.
Data can be filtered and grouped based on
time and location information. Moreover
different type of visualization should be
proposed according to the type of data
recorded.
Having the overview on how the entities
are exchanging information between each

Monitor
Edit
Ciao
Lorenzo
Final design - 77
Boolean Action
Turn on siren
Alarm Studio-Mingle
New coffe
studiolab-coffe
reception-coffe
Edit the full code
Monitor view
ENTYTY COMES ONLINE
ACTION IS PERFORMED
When entities are not connected
are going they appear desaturated
in the map view.
Whenever a building block is
executed a pop-up wit the name of
the building block will appear on
top of the entity. The pop-up fades
out after 3 seconds.

78 - TINK
4.5 TINK Workflow
Mike wants to design a network of lamp
to stay in touch with family and friends
leaving in different time zones.
He analyses the design and discovers
that he will need several components to
prototype the system.
TINK is the perfect platform to prototype
networks of connected objects. Therefore
Mike start by creating a TINK account.
He prepares the electronics by hooking up
an Arduino YUN to a lamp.
Then He start using TINK to program the
lamp behaviour. He starts by adding a new
connected object to the system diagram.
He configure the just created Connected
Object giving it an ID and defining the
location.
Mike looks in to the building block library
for an action to operate a relay. He picks
an Actionbuilding blocks called “digital
switch“
He decide to slightly modify the code
according to his electrical setup.
Then he deploys the code on to the lamp
to check that everything is working as
expecting

Final design - 79
The lamp is now connected to TINK and its
behaviour can be monitored on the system
diagram.
It’s now time to connect the other lamps
to the platform.
Other two prototype are made and shipped
to friends in new York and Shanghai.
Mike can control when the lamps will be
connected to the Internet And when they
are going to be turned on.
Mike has a new idea, he wants to receive
a notification on his phone every time all
three lamps are turned on.
He modify the system diagram adding two
new entities a data analyst and a webservice.
Since the system is all hooked up to the
platform he can remotely deploy the code.

80 - TINK
4.6 TINK technology
Web Technology
TINK is developed as a web application.
The software will run inside a web-browser
providing several advantages:
• It will be cross-platform,
• It won’t require any installation
• A Tink project will be accessible from
multiple locations
• The software will be easier to maintain
as software updates don’t require to
be installed by the user but can be
directly deployed.
TINK is structured maintaining a separation
between front-end and back-end as shown
in Figure 37.
The different part of the platform are
connected to a server, that will route all the
messages exchanged between the entities
and provide access to the database.
In order to provide real time, two way
communication between connected
objects, TINK web-app and devices Tink
make use of Web sockets.
In order to clarify how the different
components communicate to each other an
example is proposed:
Let’s consider the system made of a coffee
machine that publishes a twit every time a
coffee is made.
The connected object informs the server via
web-socket; if the user is connected to the
platform, the server will notify him/her of
the happening of the event: via web-socket
the message will be sent to the browser;
The server will also perform a http request
to the twitter server using its public API,
in order to publish the twit.
Separating front end and back-end
is crucial in the development of this
kind of application as it will improve
maintainability and performance. Moreover
it will be possible for third parties to make
use of public API to access the platform.
Via the API it will be possible to access
the data, log custom events. It will be
possible for developers to create new
interfaces to interact with TINK via custom
made interfaces.
Arduino YUN
The hardware platform that was decided
to use as core electronics for connected
objects is the Arduino YUN, a new Arduino
that combines a small Linux computer
with a small Atmel 32u4Chip. The Linux
computer gives to the Arduino the extra
power of connecting to the internet via
wired and wireless connection.
The Bridge Library for Arduino enables the
Linux side of the Arduino to communicate
to the Atmel side.
The Arduino YUN is programmed with
standard Arduino code and supports
natively 90% of the libraries and shield

Final design - 81
developed for standard Arduino boards,
making it a very versatile platform to
develop IoT applications.
Arduino YUN will be the first board to
be supported by TINK, but in the future
libraries for other hardware platform will be
released as well.
DATABASE
BACK-END
THIRD
PARTY
API
DEVICES
PLATFORM
SERVER
FRONT-END
ARDUINOS YUN
PHYSICAL
FRONT-END
Figure 37. Tink system diagram

CHAPTER 5
Testing
In this chapter, the TESTING SETUP used to evaluate the design of
TINK is discussed.
The test was aimed at evaluating the FEASIBILITY OF THE TECH-
NOLOGY proposed for TINK, as well as an interaction designer’s USER
EXPERIENCE of the platform.
These two points are examined with two different PROTOTYPES presented
at the beginning of the chapter.
The chapter ends with a list of important RESULTS gained trough the
testing.

84 - TINK
5.1 Prototyping TINK
The design phase was followed by a
prototyping phase aimed at the realization
of an experiential prototype for testing
purposes.
Considering the limited amount of time,
it was decided to directly go in the
implementation of a digital working
version of the platform without doing any
test with paper prototypes.
A digital working prototype was also
preferred as it would provoke as much
insight as possible on the design. Users
in front of a paper prototype understand
the sketchiness of the artefact and tend
to be less detailed in the feedback they
provide. Moreover, as one of the goals of
the user test is to determine how much this
platform support the sketching of complex
systems, it will be difficult to determine
this from a low fidelity prototype that is
sketchy by definition.
the idea proposed.
Figure 38 shows the technologies that
where experimented and tested during the
implementation of the two prototypes.
The picture highlights how the different
technologies were used to developed
different parts of the prototype. Because
of time constraints, the technologies were
not combined in a single platform, and two
different prototypes where developed:
• The first prototype was built
to challenge the difficulties of
connecting an Arduino to the Internet
via web-sockets;
• The second one was mainly concerned
with the implementation of the
platform’s user interface for the
purposes of the user test.
It was decided to prototype the platform
using a full stack of current web
technologies. This might not be the
most reasonable choice from a design
perspective, as it might cost a lot of time
to develop. However, the decision was
taken in order for the designer to learn
and get familiar with new technologies
that are becoming quite common in the
field of interaction design. Additionally,
developing a prototype using real web
technologies provided opportunities for
the designer to reflect on the feasibility of

Testing - 85
Backend
express
PROTOTYPE 2
User Interface
for user test
PROTOTYPE 1
Connecting a coffee
machine to the Internet
Physical frontend
socket.io
socket.io
Frontend
Figure 38. TINK technologies

86 - TINK
5.2 Connecting a coffee machine to the
Internet
The first test was aimed at understanding
how to connect an Arduino YUN to the
Internet via Web-Socket.
The first trial system was installed on the
coffee machine at the StudioLab. The idea
was to hack the coffee machine to measure
it’s usage during the day and visualize the
data on a web-page.
Developing this prototype was also a
good way to test how much a simple data
visualization can help discovering patterns
and information that otherwise would not
be evident.
A web NodeJs server based on Express
was developed. The server implements
Socket.IO in order to receive the data from
Arduino. The data is stored in a MongoDb
database and visualized on a public webpage
using a well-known JavaScript data
visualization library called d3js.
All the project’s code and the Arduino
library’s installing instructions are
published on GitHub and are retrievable
at https://github.com/lorenzoromagnoli/
SocketIOYunClient.
A proximity sensor was hidden inside the
coffee machine(Figure 40). The sensor was
able to detect if a cup was placed in front
of it and therefore count how much the
coffee machine was used along the day.
The sensor was connected to a battery
powered wireless Arduino board, developed
inside the StudioLab, called Schizzo (Figure
40). The Schizzo was connected via Xbee
to an Arduino YÙN (41) connected to the
Internet network of the faculty via WIFI.
An Arduino library was developed to
connect the board to a custom web server.
The developed library, modeled on the
SpaceBrew library for Arduino YUN, makes
use of Socket.IO library to provide real-time
bidirectional event-based communication
to the Arduino YUN. Socket.IO was chosen
as it works on every platform, browser and
device, focusing equally on reliability and
speed.
This trial ran for a couple of days recording
live data of the StudioLab’s consumption
of coffee. The data was publicly visible on
a website for the length of the experiment.
The screen-shot presented in Figure 42 is
a representation of the experiment, the
bar-chart grouped the amount of coffee
that was made be the machine every 15
minutes.
From the visualization it was possible to
identify trends on the usage of the object:
People arrive to work in the morning
between 8.30h and 10h; the consumption
of coffee keeps on growing until lunch,
when it drops because of the lunch break;
after lunch, the next peak is reached around
16h; after that, the amount of coffee keeps
on dropping until the time people leave
the office, around 18h.
What is also interesting to observe from
the data visualization is how the coffee

Testing - 87
consumption peaks correspond to the
complete hours that actually correspond
with the time people schedule meeting or
lectures.
It should be clear how this simple data
visualization already provided a lot of
information on the pattern of use of this
object. This is a good confirmation of
the fact that visualizing data is the first
step to comprehend patterns and observe
behaviors previously unknown.
Figure 39. The coffe machine of
the experiment
Figure 40. Schizzo + proximity sensor
Figure 42. Screen-shot of the web-page visualizing the coffee machine usage
Figure 41. Arduino YUN with Xbee shield

88 - TINK
5.3 Prototyping the user interface
A second prototype was developed with the
intention of running a user test to evaluate
the user experience of TINK.
The development of a fully functional
prototype of the entire system goes beyond
the scope of the project because it would
require months of development.
Instead this partial prototype focused just
on the implementation of the edit view,
and to left out the monitor view.
Time constraints also made it impossible
to integrate the work done for the first
technology test in the second prototype.
The prototype was therefore not functional,
as it was unable to connect to physical
“connected objects“ (Arduino YUN).
What was functional on this prototype were
the main elements of the interface (the
edit view to sketch and edit the system
diagram) as well as the back-end used to
save users information and save projects.
The developed prototype will therefore be
able to:
• Create a new project
• Access the system diagram editor
• Add entities to the diagram
• Add building blocks to the entities
• Connect building blocks with each
other.
The prototype developed won’t allow to:
• Share the project
• Access the map view and visualize the
data
• Edit the code
• Use the different types of building
block connectors
• Upload a custom picture for the
entities
• Clone entities
• Deploy the software
• Get real time feedback
• Access the building block library
The prototype was built on top of the stack
of JavaScript technology shown in Figure
38.
The front-end was implemented using
AngularJs, a framework that facilitates the
development of dynamic web applications.
Since in modern browsers it is possible to
include SVG tags into web pages, it was
decided to use the vector markup language
to code the system diagram. This was
mainly adopted to solve the problem of
drawing arrows to connect one building
block to another and be able to arrange
elements freely in the page.
The back-end, with the role of storing data,
was built on top of SailsJs, a web framework
aimed at the development of real-time web
application. SailsJs is able to automatically
generate the required API to interact with
several types of databases. Moreover it

Testing - 89
natively supports SocketIO allowing an
easy integration with the Arduino library.
MongoDB was chosen for the project as
it provides several advantages for data
intensive types of applications.
The generated APIs where used to connect
front-end and back-end.
Figure 43 shows the interface of the
prototype developed, an example project
representing a simplified version of the
system diagram of the Goodnight Lamp 24
project was drawn for demonstration
purposes .
Figure 43. Screenshot of the
prototype of TINK’s interface.

90 - TINK
5.4 User Test
As described in the previous chapter,
TINK is a big platform made of several
components. While testing the entire
platform would require an extended test
with a fully functional prototype, a user
test was performed using the partially
developed prototype.
The test focused on understanding how
interaction designers with different levels
of technical skills use TINK to sketch a
system diagram of Connected Objects.
5.4.1 User test goals
As the main contribution brought by TINK
is the possibility of sketching system
diagram of connected objects composed
of multiple entities and devices, the test
examined the following research questions:
• Does the platform allow the sketching
of system diagram of IOT kind of
products?
• Is the naming scheme used for the
platform comprehensible?
• Do interaction designers feel
empowered by TINK?
• Do programmers feel facilitated by
TINK
• Is the interface usable?
5.4.2 User test setup
Similarly to the layout of the user research,
the test involved six interaction designers
with different levels of programming skills.
Each hour long session had two participants
working together.
The participants involved in the study
never saw the platform before the test.
The test, divided in 4 phases were videorecorded
for future analysis.
The main phases of the test consisted
of designing a connected products, and
representing the system diagram of it; first
on paper and then using TINK.
1)DESIGN A CONNECTED PRODUCT (10min.)
A design assignment was given to the
participants:
MY SOCIAL LIFE
How can I become less entwined with
social media? Social media appears
to eat the time and energy that I
would rather spend with my friends
and family in real life. Do I feel I will
miss out on important updates? What
does it mean to be connected through
social media? Could you invent a way
to move me from online to offline
interactions with my friends? How
can I move from social media to
social life?
Because during the first session it was
observed that the participants were taking
much more time than expected to come
up with an idea due to the complexity of
the assignment, in the second and third

Testing - 91
session the assignment was reformulated
in a more concrete example.
EXPRESSING AVAILABILITIES
Due to our constant connection to
the internet trough different mobile
platforms and devices, we are always
reachable.
Refusing a call might result in a
bad experience for the caller, but is
sometimes necessary.
How can we notify our availability to
friends and family trough a tangible
interaction?
The participants where asked to brainstorm
on the assignment and design a product
that would solve the given problem. At
the end, they where asked to represent a
system diagram of the designed product on
paper.
3) USE TINK (25min.)
In the third phase the participants had to
use TINK to draw the system diagram for
the product envisioned in the first phase
of the session. Help was provided by the
facilitator just in case the participants got
stuck or when explicitly requested.
4) INTERVIEW (15min.)
Once the participants where satisfied with
their system diagram they were asked
to explain it. An interview was then
conducted to discuss their experiences,
the difficulties they encountered with the
interface and gain feedback on the overall
experience.
Figure 44. Setup of the user-test
2)EXPLANATION OF TINK (10min.)
TINK functionalities where then
demonstrated and explained to the
participants. The roles of the different
entities and building blocks of the TINK
system were described to the participants
and also provided to them in a printout,
which would be available for their reference
in the next phase of the testing.
It was highlighted during the presentation
how important it was to give selfexplanatory
names both to the entities and
to the building blocks.

92 - TINK
5.4.3 User test results
The test produced a lot of useful data and
insights. Participants generally had positive
experience with the concept behind TINK,
a functional and easily adaptable system
diagram.
The purpose, function and aesthetics where
understood and appreciated by users.
Testing did reveal several usability
dimensions of the platform that could
be improved. Some of these confusions
are rooted in the functions of the
prototype being tested on, and its
limited functionality. Other challenges
have straightforward resolutions which
are addressed in the next chapter of this
report.
PLATFORM’S PURPOSE
The main objective of the platform is to
support the interaction designer build
experiential prototype of complex system
of connected object.
Both expert coders and designers with no
previous coding experience experienced
the platform positively. The graphical
representation of the entities on a
system diagram was considered useful
and necessary especially for interaction
designers that are not used to deal with
complexity. In one participant’s words:
It help visualizing [..] it makes
it much easier to write the code
since it creates an overview on the
system. You will have to think more
consciously at all the requirements
and pieces you will have to build.
The participants experienced positively the
completeness of the platform, even though
the facilitator had to intervene several
times to clarify some matters. The entities
included in the platform allowed everyone
to represent the envisioned design.
SKETCHINESS
The sketchiness of the platform was
not evaluated positively. Participants
found usability issues with the system.
In particular they found the process of
drawing the system diagram cumbersome
and slow.
It must be considered however that the
prototype tested was not comprehensive
of all the functionalities and presented
several bugs.
The fact that no real object could be
connected to the platform, and the
absence of real-time feedback, influenced
the evaluation of the sketchiness of the
platform. Moreover the impossibility
of testing the behaviour of the system
diagram produced, prevented the user
the possibility to iterate on their design
and made the participants experience the
representation of the system diagram as a
very mental exercise. It must be highlighted
how this observation are really far from the
intentions of the design.
Most importantly, some participants in the
testing found that the platform provided
inspiration for how to develop the original
concept while using TINK.
This supports the thesis that TINK can
facilitate idea generation, and iterative

Testing - 93
development of design.
USAGE AND UNDERSTANDING OF THE
DIFFERENT COMPONENTS
The platform proposes several names to
distinguish the different types of entities
and building blocks.
Even without full functionality of the
platform users were mostly able to
understand the names used to understand
different elements. Generally speaking the
entities where understood correctly.
The ‘Data Analyst’ entity was the only one
that left the participants with some doubts
about its role. While a more understandable
name could be found, I believe that the
meaning of the entity could become clear
once the user will be able to experience its
functionalities.
The representation of the data analyst on
the system diagram was also experienced
as somewhat confusing because of the way
it is represented on the system diagram:
1) The way it is represented doesn’t
highlight the fact that the data analyst is
able to have an overview on the rest of
the system, as it is able to access data
recorded by any other object. Making this
metaphor more visible graphically would
lead to a better understanding of the role
of the entity.
2) More confusion arose by the fact that
the connections between data to track
building block and data analyst are not
required. Test Participants expressed their
expectation of this connection
BUILDING BLOCKS
The building blocks were more confusion
then the entities to the participants.
This might be related to the fact that in
order to operate on the building blocks a
bigger level of understanding on how the
system works is required.
While designers with more technical skills
where able to understand the difference
between a trigger and an actuator, this
was more confusing to people with no
coding experience.
The correct interpretation of the building
blocks was also influenced by the fact
that during the test it was not required
for participants to fill in the code of the
building blocks. The participants that were
able to code would have understood better
how to make use of them if they would
have been told what is actually behind the
building blocks.
Designers with less technical skills
sometimes had problems in correctly
understanding the difference between
triggers and actions. This can be related
to the possible shift in perspective that
is required when dealing with technology:
while designers are used to think from the
user perspective, technologists are more
used to think in term of the technology’s
perspective. For instance a “press the
button” was interpreted as an action by a
designer while it was correctly understood
as a trigger from the developers.
Dividing the system diagram in different
building blocks was sometimes not
done in the expected way. For instance,
instead of dividing object’s behaviours in
all the possible state of that action, the
participants often tended to group all those

94 - TINK
state in a single action. This approach does
not go in the direction of creating minimal
building blocks.
The building blocks library addresses this
issue by proposing examples building
blocks and a guideline to structure them.
The same issue could also be solved by
providing example projects that would
show the advantages of this code folding
practice.
also different from programming with MAX-
MSP or other visual programming languages
that expose every single functional
element to the user. TINK proposes a way
of programming that is more close to the
concept of flow based programming.
While new user won’t find big problems in
adopting the new paradigm, experienced
users, who have worked for years in this
other platforms might find it more difficult
to switch to this new coding paradigm.
The role of the “data to track” building
block was considered confusing as well.
This was mainly due to the fact that it was
proposed on the same level of triggers and
actions.
Participants to the test were more
accustomed thinking at Arduino as a black
box that produces output according to an
input provided.
Because of this assumption, the ‘data to
track’ building block was often interpreted
as the one that reads raw data from the
sensors. The triggers as a condition or a
mapping function on the data, and the
action was correctly understood as the task
performed by the entity.
LEARNING CURVE
The platform is quite big and therefore
it requires time to be explored and fully
understood. The way the platform should
be used is quite novel from other tools
users might be used to.
Coding with TINK is different from coding
with Arduino and other imperative
languages, as the code is supposed to be
fragmented into building blocks. But, it is
USER TEST SETUP
During the second session, testing the
platform’s user interface, the participants
could not find any way to transfer messages
from one building block to another.
This lead them to sketch a system diagram
that made intensive use of the data to track
building block and data analyst entity,
instead of Trigger and Action Building
Block. Thus resulting in a System diagram
not representing all the connections and
relations between the entities.
While this way of using the platform should
be discouraged, as it goes against the idea
of visualizing the behaviour of the network
of entities in the form of the system
diagram. It can be said that the platform
demonstrated a big level of openness as
participants discovered way of using it not
envisioned by the designer. In addition, the
current version of the design introduced in
the previous chapter, already presents the
possibility to exchange messages between
objects and it could be enough to solve
this issue.

Testing - 95
When developing experiential prototype
choices are made in order to adopt the
easiest and quicker way to get to an
artefact that is functional to the testing
of the experience. This most of the time
require the designer to make a compromise
between developing with the envisioned
technology or downscale the design due
to the difficulties of implementing a final
prototype.
The prototype used during the test did
not providing any kind of limitation as to
what kind of hardware could be connected
to it, or which kind of web-services could
be used. During the test, participants were
trying to implement all the details of the
interaction in the system diagram. However
a confrontation with the real limitation of
the platform would have made them reflect
and came up with more practical solutions
to achieve the same envisioned experience.
USABILITY
Participants found the interface
aesthetically appealing, and appreciated
its clarity and simplicity.
Several usability issues were however
discovered during the user test. Several of
these were bugs and interface design flaws
the designer had already been aware of.
The user test was fundamental in
uncovering other specific aspects of the
platform to improve.
Dragging
The test participants tried to use the drag
and drop gesture to perform actions that
were not supported by the platform, or
that were implemented differently.
One particular usability issue was
discovered in how the mouse was used
with the connection function.
When the mouse was being used to drag a
connection between to building block, it
was not clear where or when the mouse was
supposed to be released
The next chapter offers some
recommendations on how to improve the
platform’s gestural interfaces, which will
improve the usability of the drag and drop
gestures.
Consistency
The current design features a single button
with a plus (+) to add entity, which
after rotating the button by 45° degrees
becomes an x icon to close the same
panel. The little detail was not properly
understood by participants and took some
time to figure out that the same element
was both used to open and close the same
panel.
Order
Sometimes creating complex systems with
TINK resulted in a messy tangle of lines.
This doesn’t facilitate the comprehension
of the system diagram. A routing
mechanism should be proposed to avoid
this to happen.
Some participants also expressed the desire
to be able to rearrange the building blocks
around in order to be able to be able to
visually group blocks building blocks
together and make the representation of
the system diagram more free and at the
same time more comprehensible.

CHAPTER 6
Evaluation
Here, the graduation project as a whole is evaluated.
Firstly, by considering the MAIN CONTRIBUTIONS that TINK would
bring to the field of design.
Then with a reflection on how well the PROGRAM OF REQUIRE-
MENTS IS SATISFIED.
Next, an extensive list of RECOMMENDATIONS for future development
of TINK is offered based on the results of the user tests.
The chapter closes with a PERSONAL EVALUATION of the work done.

98 - TINK
6.1 Main contributions
What follows is a point to point evaluation
on the program of requirements presented
at the conclusion of chapter 3.
provides crucial insights that will inform
the design process.
1)TINK provides a structure to organize
and represent system diagrams.
System diagrams are well known, and
necessary tools to engineers and software
developers, at the same time, because of
their graphical appeal, can easily be drawn
by interaction designers. Tink serves as a
base for cross-expertise discussion between
designers and developers, Its robust
technical components adequately serve
the needs of developers while the graphic
appeal speaks to the design community.
3)TINK combines all the features needed
for developing connected object in a
single platform
TINK is a complete platform; designers
won’t have to switch between different
tools in order to build their experiential
prototype of connected objects.
Other existing platforms aren’t as allemcompassing.
TINK combines functions
of several different programs into a single,
stream-lined platform and process.
2)TINK is for all stages of the design
process
TINK supports the designer throughout
the entire process of creating a connected
object.
It supports the early exploration and
sketching phases, and also allows
interaction designers to make informed
decisions, refine and modify the initial
idea, all the way up until an experiential
prototype of the final product is made.
TINK supports quick iterations and testing:
the behaviours of the system can be
modified on the fly and tested. Moreover,
it allows the tracking of data from the
beginning of the design process; which
4)TINK support designers in structuring
the code.
Code is structured and hidden inside
TINK making it reusable and easy to
write. Even interaction designers with no
coding experience can access TINK basics
functionalities, make use of the building
block library, and draw system diagrams.
Typically interaction designers writing
Arduino code rely on using code found
from other sources (be it on the Internet or
from an example folder) and copying and
pasting it into their project. However, this
collage of different snippets of pre-formed
code from multiple sources tends to create
conflicts and can not easily be tailored to
individual projects.

Evaluation - 99
With TINK however, pieces of code are
structure in such a way that makes them
autonomous from other pieces. Thus
allowing a graphical representation of
them in building blocks, the Autonomy of
the building block from each other makes
it also possible the to save them into a
building block library, for a future reuse in
to other projects.
This building block library leverages the
practice of looking for pre-written code
online interaction designers are used
to, offering this service within the TINK
platform itself. The library provides an
official repository of working snippets
that can be integrated inside the project--
without even looking at the code.
5)TINK promotes social coding and
group-work
A big open source community is driving
the market of DIY tools for prototyping.
TINK’s design builds on this value of
communality with its own platform library
which promotes and encourages users to
contribute their own code as a building
block for their personal project, as well as
that of others.
Group-work is additionally facilitated
by TINK’s general usability across a
multidisciplinary team; as well as by the
fact that it is an online platform that can
be accessed by multiple people in real
time.

100 - TINK
6.2 Reflection on the program
of requirements
A reflection on the program of requirement
presented in chapter 3 is important for a
correct evaluation of the design.
2)Target users
1) Platform goal
1.1 The design of TINK allows, for
networks of connected objects to
be developed, it make possible the
development of experiential prototype of
networks of connected object, and also
the development of experiential prototype
part of other Connected Object categories
presented in chapter 2.
1.2 The result from the user test cannot
evaluate the sketchiness of the platform,
since several features were missing
from the prototype itself. Several TINK’s
features however can be re-conducted to
sketchy qualities: TINK in fact improves the
speed of developing networks of connected
objects, supports exploration of different
solutions, provides direct feedback to
the user allowing for quick iterations and
inspiration for the user about different
possibilities and potential of the network
created.
1.3 Tink allows the storing and visualization
of data. The evaluation of the data is left
to the user, the visualization is already a
powerful tool that supports the designer
in understanding and observing recurrent
patterns within the data.
2.1 The main target users of the software
are interaction designers. While the
software provides several levels of access
for users with different skills sets, in
order to access the most of the potential
of TINK, a minimum of understanding of
Arduino coding is needed.
2.2 While it is debatable whether it is
necessary for interaction designer to learn
how to code, this platform can and does
provide support to interaction designers
with no coding knowledge. Some ideas
on how this goal could even better
implemented will be discussed in the
recommendation section.
3) Versatility
3.1 TINK can assist the development of
experiential prototypes at all steps of the
design process.
3.2 The ‘building block’ function allows
for exploration of different possibilities,
inspiring the user to test different solutions
before getting to a final design.
3.3 The platform doesn’t force any strict
work-flow: Users can start by defining the
layout of the entire system diagram or
start by testing each trigger and behaviour

Evaluation - 101
related to an entity before adding the
second one.
3.4 The monitor view, meant especially for
testing purposes, can also be very useful
in the beginning of the process as it might
give the designer relevant insights for the
continuing of the project.
4) Openness and level of
visibility
4.1 The platform provides different level of
accessibility:
As discussed during in the section on the
user test, TINK helps designers having an
overview on the system and at the same
time allows the designer to go in to the
detail of the interaction. Since the building
blocks are not fixed, the behaviour of every
single block can be personalized via code.
The platform also supports the ability to
separately test each and every single
aspect of the interaction.
4.2 The software helps designer deconstruct
the envisioned interaction in different
parts: The users testing the platform had
no difficulty identifying the type of entities
that they needed in their design. However,
the division of the actions into building
block was not always done as expected:
while engineering are used to the division
in functional building block, designers
tent to talk about the interaction with the
system on a bigger level of abstraction.
Suggestions on how to improve the design
according to the requirement are provided
in the recommendation section of this
chapter.
4.3 The software was developed based on
open source software and hardware, all the
code produced for the project can be found
on GitHub.
The possibility of operating the software
prior to the electronic being connected
is an important feature envisioned in the
design that unfortunately could not be
tested.
5) Usability
5.1 The platform provides users with
several ways to get feedback on the status
of the network’s hardware. The entities in
fact visually display when they are not
properly connected to the platform.
5.2 Moreover, whenever a building block is
executed, visual feedback is presented to
the user showing the value of the message.
5.3 The usability of the platform presented
several issues during the user test, most of
these problems however were connected to
the level of development of the platform.
The overall usability experience of the
platform was positive.

102 - TINK
6.3Recommendations
What follows are some recommendations
and ideas for further developments of the
platform based on the findings from the
user tests
TARGET USERS
confusing and redundant. A possible
solution would be to enable each building
block to track its own data produced.
The metaphor of the recording button
(Figure 46) could be used as a reference
button for users to enable this feature.
Figure 45. Proposal for more
explicit building blocks
Figure 46. Using the methaphore of
the record button to track data
While the platform already wants to be
designer friendly, it still can sometimes
favour an audience that is fluent with
coding. Future iterations of this platform
could be designed to be even more
accessible to a non technical audience.
BUILDING BLOCKS
As observed during the user test, the most
critical point that designers with little
coding experiences found confusing was
the structure of the building block. Some
small and simple changes can begin to
resolve these conflicts.
Just by adding few words before the name
of the building blocks some guidance can
be provided on the role of the different
types blocks.
IF, DO can be placed respectively in front
of the trigger and action blocks to aid in
clarifying the meaning of the block for
users. (Figure 45)
TRACKING DATA
Test users building found having a building
block dedicated to the tracking of data
ENTITIES
An attempt was done in making all entities
consistent: All of them have similar
representation style, and the same set of
building blocks.
This choice should be reconsidered. Having
more tailored properties for the different
entities might actually result in a better
user experience of the platform.
Because the coding/detailing of the
building blocks for the other entities
still need to be tested with users, there
is room for in-depth analysis of the
advantages and disadvantages brought by
the customization of the different entities
in terms of structuring, representation,
naming etc...
Connected object
An approach to making building block
more friendly for designers would be to
restructure the dichotomy trigger-action of
the building block format into a structure
that more accurately mirrors the setup of
the physical prototyping board.
I often hear fellow interaction design

Evaluation - 103
students talking about Arduino as a black
box that produces some output according
to some input (Figure 47).
and “trigger” building block, the role of
an action building block might be not
necessary.
This vision could be explored in a future
TINK iteration dividing the working logic
represented now in trigger->action in
input->mapping->output as presented in
Figure 48.
This division might provide several
advantages for an interaction designer
that are is used to code as it is also closer
to the way sensors (input) and actuator
(output) are physically a attached to the
electronic prototyping board.
On the other hand, this separation of roles
proposed here may actually be experienced
as limiting by more advanced users. The
choice of a more specific target group
might be useful in understanding how to
improve the definition of the behaviours of
the entity.
Data analyst
A different structure could be proposed for
the implementation of the Data Analyst
entity based on the type of features that
the entity requires to perform:
• Represent data of the collective
behaviors of multiple entities
• Create alerts (triggers) on particular
group behaviors observed.
While the two feature explained might be
satisfied by the role of the “data to track”
Another proposal can be made on how the
entity should be further developed.
As the main role of the entity is to inquiry
the database, the programming language
to operate on this entity should be similar
to common filtering/querying mark-up
used for similar purposes.
A good starting point could be looking
at how filtering and querying is done on
spreadsheets.
However, as it should be possible to define
action on the data collected some sort
of programming logic should be adopted
to create conditions and triggers on the
elaborated data.
To provide direct feedback to the user
on what kind of data he/she is trying to
collect, it will be important to provide the
data-visualizations representing the result
of the query (Figure 49).
Web service
The web service object is probably the one
that was more successfully envisioned and
executed. For this entity, the meanings of
triggers and action building blocks were
fully understood.
For the further development of the entity,
I suggest to investigate the possibility of
an integration of TINK with third party
services such as Temboo and IFTT that
Figure 47. Arduino: a box that
produces outputs according to
the inputs
Figure 48. Restructuring the
building blocks in input, mapping,
output.
Figure 49. Providing visual
feedback to data queries

104 - TINK
already provide a reach set of API to
interact with web services.
As connecting to third part API is always
quite an advance feature, some sort of
building block library will be very useful to
provide designers with a rich set of options
to choose from. This also will inspire the
designer in finding new solutions.
Device
DRAGGING
While the interface already supports the
drag and drop of entities and arrows, the
gesture should be used to support also
other kinds of actions in order to provide
a more consistent experience. Drag and
drop could be for example used to add and
delete entities, and to reorder building
blocks.
The role of the device is maybe the least
clear aspect of the entire platform, It could
be implemented in different way with
different goals in mind.
In addition, whenever a dragging action
start, the possible target for the dropping
should highlight in order to provide
guidance to the user.
Figure 50. An Idea to develop
interfaces to interact with TINK
The easiest approach would be to define
a set of APIs that would allow designers
to send and receive information from the
platform. This will require users to write
code or use other tools that can produce
interactive prototyping of user interfaces.
For example someone could build an
interface in html and define js/ajax call to
TINK server to retrieve or post data on-line.
This approach is similar to what Space
Brew 40 and Noam 41 are capable of.
Designing a system to create simple
interfaces from the platform itself, able to
connect to the other entities would be a
more designer friendly solution.
Simple UI elements such as forms, buttons,
sliders, graphs could be just dragged and
dropped and connected to the system
diagram. (Figure 50)
SCALABILITY
TINK is meant for building experiential
prototypes and facilitating the design
process. At this stage, the platform can’t
be to deploy system in to production and
won’t support the deployment on large
number of nodes. However solutions to
facilitate the scaling of a prototype to
production could be investigated.
CONNECTING THIRD PARTY OBJECT
While TINK allows to connect custom
Connected Object between each other
based on Arduino YUN, TINK not yet allow
interactions with other third party objects.
However with the burgeoning development
of IoT objects come plethora of possibilities
for future connectivity with TINK. TINK

Evaluation - 105
should provide tools to interact with third
party objects API. (Figure 51)
the possibility offered by the Web Service
entity from the connected object
DEVELOPING THE HARDWARE
While TINK supports interaction designers
with building the software, it doesn’t help
the designer in dealing with the hardware.
As discussed in the beginning of the
report, developing hardware remains a big
challenge for designers.
TINK could support the development of
electronics by providing tutorials on how
to hook up hardware to the platform. These
tutorials could be integrated within the
building block library in order to provide
a clear correlation between code and
hardware.
ROADMAP
The development and release of the
platform can be done in several incremental
steps.
1) The first alpha version of TINK will just
include the possibility of working with
connected objects. It will be possible
to visualize the data collected by those
objects and access the functionalities of
the monitor view.
2) The building block library will be added
featuring a selection of building block
related to the official Arduino Libraries
(LCD, servo, stepper etc…)
A Temboo library will be released as well
so that user will be able to access some of
3) The Data Analyst entity will be released.
It will include the possibility of doing data
analysis on the collected data and create
triggers related to the combined behaviour
of the object in the system.
As this feature is not implemented in any
tool on the market, extensive testing will
be necessary to determine the effectiveness
of it.
4)TINK Web Service entity will be
released. The Temboo library will remain
as a secondary alternative for connecting
objects to third party services such as
social networks.
5)The device entity will be implemented
and released gradually. Firstly, the
possibility of creating a device trigger
will be implemented. This will work as a
custom web address, to which the user can
make a post request, passing the data, in
order to activate a trigger on TINK’s system
diagram.
The designer will have to write the code to
draw the interface and make the request.
The Device entity could then evolve in the
direction of creating a GUI to design the
interface and link it to other entity.
Figure 51. Proprietary entities

106 - TINK
6.4 Personal Evaluation
The project resulted to be a long and
passionate journey.
I have to admit that I started working
on this project with several personal side
goals in mind.
Even though in the beginning I had no clue
what I was going to design, I knew that
I wanted to do a graduation project that
would end with a “final design”: I didn’t
want to end up my final project presenting
just a sketchy concept but I wanted to get
to the point of designing the details of
it. Moreover, even though I had no clue
about what I was going to be designing
for, I knew that I wanted to produce a fully
working prototype of the final design.
Looking back at it, I have to say that those
goals where quite ambitious considering
how broad the assignment was.
I started the project trying to free my mind
from any preconception of what I could
have end up designing, trying to be as
open as possible to any inspiration that
would strike me.
It ended up to be a 7 months of intense and
satesfactory work, almost evenly balanced
between research and design.
I’ll present here several Highlights that I
valued from this long journey.
RESEARCH
The ‘following the flow’ approach resulted
in devoting a lot of this project’s time in
research.
I was not expecting this from the
beginning, as I consider myself more of
a “maker“ than a “researcher”; however I
found the activity of building knowledge
quite gratifying.
While I’m really pleased with the results
from the market analysis concucted, the
two highlights I want to mention about
this phase are related to the user research
and the week spent on “the philosophy
book”:
- I’m not a big fan of user research, I’m of
the opinion that we cannot really ask our
users what they want as they are not aware
of what they might want. However I have
to say that in this project, the research
done with users was very insightful.
As I love arguing (I guess my mentor team
realized that), but I was not working in a
team, the user research was probably the
best way to question my choices.
- At some point in the process my mentor
suggested to read a book about the
phenomenology of things 7 , the importance
findings I got out of this book are
summarized in chapter one. I have to say it
was the most relaxed week of my project, it
was a welcomed diversion and inspiration
to my project

Evaluation - 107
DESIGN
After the research phase I jumped into the
design. Probably my approach to it was
probably not very conventional, as instead
of producing many ideas, I jumped straight
in to wireframing the features of a huge
application.
I pushed myself to go into the details of
the app as soon as possible, to work on
shapes, colors, animations and the little
interaction details.
I’m happy for the way I managed to
include most of the knowledge built along
the process inside the design of TINK. The
process of including different features in
TINK was very smooth and never forced.
PROTOTYPING
I like to use every project I take on as an
opportunity to learn some new skill sets.
In this project I decided that I wanted
to experiment with some state of the art
web technologies: Most of the technology
and frameworks I used to develop the
two prototypes previously described were
new to me, and, of course, it didn’t go as
smoothly as expected.
In the end, I couldn’t manage in fact to
achieve my goal of a fully functional
prototype because of time constraints.
I could have probably developed a working
prototype of TINK using other kinds of
technologies I’m more confident with, in
probably half the time. While this might
have lead to a smoother end of the
graduation project, especially regarding
the setup and result from the user test,
I‘m still happy that I took the chance to
experiment and learn new stuff.
PROJECT’S RESULTS
I have to admit that I’m really pleased with
the results of my work.
Both with the results from the research
phase (communication model and
categories of connected objects), and with
the final design.
TINK is not ready to be announced as a
magnificent tool to develop experiential
prototype of connected products, as
demonstrated by the user research.
And this makes totally sense as it is just
the result of a 7 months solo graduation
project.
However I believe that with my Graduation
project however I managed to properly
investigate the topic, gaining a lot of
insights that might be used in a redesign
of the platform or in a new design.
For sure one of the most important results
is the learning experience that I got from
the project.
CONCLUSIONS
In summary, with this project I was not only
able to develop and build a novel concept
and tool, it was also an opportunity to
explore new skills, ways of thinking and
important phases of the design process
that I had not yet been exposed to.
For this project, I not only developed
my pre-existing area of expertise, but
also explored other critical fields and
dimensions of design. I appreciate and
value the experience of this project because
it made me a more informed, thoughtful
and technical interaction designer

108 - TINK
References
1. Buxton, B. (2010). Sketching User
Experiences: Getting the Design Right
and the Right Design: Getting the Design
Right and the Right Design. Morgan
Kaufmann.
2. Ashton, K. (2009). That ‘internet of
things’ thing. RFiD Journal, 22, 97-114.
3. Reas, C., & Fry, B. (2006). Processing:
programming for the media arts. AI &
SOCIETY, 20(4), 526-538.
4. Victor, B. (2012, September 1). Learnable
programming. . Retrieved June 1, 2014,
from http://worrydream.com/#!/
LearnableProgramming
5. Moussette, C., & Dore, F. (2010). Sketching
in Hardware and Building Interaction
Design: tools, toolkits and an attitude
for Interaction Designers. Proc. of Design
Research Society
6. Resnick, M., Myers, B., Nakakoji, K.,
Shneiderman, B., Pausch, R., Selker, T.,
& Eisenberg, M. (2005). Design principles
for tools to support creative thinking.
7. Verbeek, P. P. (2010). What things do:
Philosophical reflections on technology,
agency, and design. Penn State Press.
8. McLuhan, M. (1994). Understanding
media: The extensions of man. MIT press.
9. Stappers, P. J. (2009). Meta-levels in
Design Research.
10. Kuniavsky, M. (2010). Smart Things:
Ubiquitous Computing User Experience
Design: Ubiquitous Computing User
Experience Design. Elsevier.
11. Bleecker, J. (2006). A manifesto for
networked objects—cohabiting with
pigeons, arphids and aibos in the internet
of things.
12. Sterling, B., Wild, L., & Lunenfeld, P.
(2005). Shaping things. Cambridge, MA:
MIT press.
13. Rubino, S. C., Hazenberg, W., & Huisman,
M. (2011). Meta products: Meaningful
design for our connected world. Bis
Publishers.
14. TOTeM Labs. (2010, April 1). Tales of
Things. Tales of Things. Retrieved June
18, 2014, from http://talesofthings.com/
about/
15. OV-chipcard F.A.Q. (n.d.).OV-chipkaart.
Retrieved June 18, 2014, from https://
www.ov-chipkaart.nl/klantenservice/
vragenenantwoorden/
16. Smartcitizen. (2012, January 1). Smart
Citizen. Retrieved June 18, 2014, from
http://www.smartcitizen.me/pages/
smartcitizen
17. Ricker, T. (2012, April 23). Fitbit Aria Wi-
Fi scale review. The Verge. Retrieved June
18, 2014, from http://www.theverge.
com/2012/4/23/2966393/aria-scalereview-fitbit-wi-fi
18. Google and Adidas Unveil a ‘Talking Shoe’
at SXSW | Special: SXSW - Advertising
Age. (2013, March 1). Advertising Age
Special Report SXSW RSS. Retrieved June
18, 2014, from http://adage.com/article/
special-report-sxsw/google-adidasunveil-a-talking-shoe-sxsw/240299/
19. Spitz, A. (2012, October 1). Skube - A
Last.fm & Spotify Radio . { sound + design

References - 109
}. Retrieved June 18, 2014, from http://
www.soundplusdesign.com/?p=5516
20. About Instacube. (2014, January 1).
Official Instacube Website RSS. Retrieved
June 19, 2014, from http://goinstacube.
com/about-instacube/
21. Carnoy, D. (2007, April 1). Ambient
Devices’ weather-forecasting umbrella
now available - CNET. CNET. Retrieved
June 19, 2014, from http://www.cnet.
com/news/ambient-devices-weatherforecasting-umbrella-now-available/
22. Introducing Philips hue: the world’s
smartest LED bulb, marking a new era
in home lighting. (2012, October 29).
Introducing Philips hue: the world’s
smartest LED bulb, marking a new era
in home lighting. Retrieved June 19,
2014, from http://www.newscenter.
philips.com/main/standard/news/
press/2012/20121029-introducingphilips-hue.wpd#.U6KUmo2SxgM
23. Discover LG Smart ThinQ Appliances.
(n.d.). Smart Appliances: Discover LG’s
Smart ThinQ Appliances. Retrieved June
19, 2014, from http://www.lg.com/us/
discover/smartthinq/thinq
24. About us. (2014, January 1). The Good
Night Lamp. Retrieved June 19, 2014,
from http://goodnightlamp.com/about/
25. Samani, H. A., Parsani, R., Rodriguez,
L. T., Saadatian, E., Dissanayake, K. H.,
& Cheok, A. D. (2012, June). Kissenger:
design of a kiss transmission device. In
Proceedings of the Designing Interactive
Systems Conference (pp. 48-57). ACM.
26. CitySense - Tvilight. (n.d.). Tvilight.
Retrieved June 19, 2014, from http://
www.tvilight.com/products/citysense/
27. Addicted Products, a scenario of
future interactions where products are
addicted to being used” S.Rebaudengo,
W.Aprile, P.Hekkert, Design and Emotion
conference, 2012
28. Arduino – FAQ (n.d.). Arduino. Retrieved
June 30, 2013, from http://arduino.cc/
en/Main/FAQ.
29. O’Sullivan, D., & Igoe, T. (2004). Physical
computing: sensing and controlling the
physical world with computers. Course
Technology Press.
30. Lego Mindstorms user guide. Retrieved
June 19, 2014, from http://www.lego.
com/en-us/mindstorms/downloads/userguides/enus/
31. Powell, R. (2012, July 1). Programming
for Interaction Designers. . Retrieved ,
from http://repository.tudelft.nl/view/
ir/uuid%3Af4c76373-a1d6-4bf8-b002-
9ddecb58e9d9/
32. Greenberg, S., & Fitchett, C. (2001,
November). Phidgets: easy development
of physical interfaces through physical
widgets. In Proceedings of the 14th
annual ACM symposium on User interface
software and technology (pp. 209-218).
ACM.
33. R/GA. (n.d.). Nike+ FuelBand - R/
GA. RGA. Retrieved June 19, 2014,
from http://www.rga.com/work/nike-

110 - TINK
fuelband/
34. BAJARIN, T. (3012, November 1).
How Bluetooth 4.1 and BLE Will Drive
New Innovation. . Retrieved June 19,
2014, from http://www.pcmag.com/
article2/0,2817,2427234,00.asp
35. Haque, U. (2004). Pachube project.
Pachube project.
36. Xively. (n.d.). What is -. Retrieved June
19, 2014, from https://xively.com/
whats_xively/
37. About Temboo. (n.d.). About :: Temboo.
Retrieved June 19, 2014, from https://
www.temboo.com/about
38. WeMo switch. (n.d.). . Retrieved June
19, 2014, from http://www.belkin.com/
us/p/P-F7C027/
39. Patterson, S. M. (n.d.). How the ‘Internet
of Thing’ will become the Internet of
Things. Network World. Retrieved June 19,
2014, from http://www.networkworld.
com/article/2365080/opensourcesubnet/how-the-internet-of-thing-willbecome-the-internet-of-things.html
40. About. (n.d.). Spacebrew. Retrieved June
20, 2014, from http://docs.spacebrew.cc/
about/
41. Bridge The Gap Between Hardware And
Software.. (n.d.). noamio. Retrieved June
20, 2014, from http://noam.io/

References - 111