Industrial Design Final Master Project Design of a tangible Programming Tool
January 2015
Name:
Coach:
Portfolio
Info
Tijmen van Gurp
Jacques Terken
www.tijmenvangurp.nl
Industrial Design final master project report. Technical University of Eindhoven. Theme: Next Nature
Contact mail@tijmenvangurp.nl
TABLE OF CONTENTS
INTRODUCTION WHY HOW WHAT SEMESTER 1
06
15
Cubi will be a tool available in primary schools as a tool for teachers to explain programming in an intuitive way...
In preparation for the final master project, a proposal was written based on my explorations of existing tangible programming tools. A first design probe was made to explore the solution space and to define goals for the rest of the project.
Goal
04
What Is Cubi? Cubi is an intuitive tangible programming tool made for children to explore the very basic concepts of programming that are needed to understand the verity of programming languages that exist...
09
Theoretical background and argumentation Why do we need a tangible programming tool?
Acknowledgements Jacques Terken: Guidance, motivation, and planning Pepijn Kroes: Programming expertise Tom van t’ Westeinde: Expertise in concept development Marieke de Rooy: Electronics Henriette Marciello: Personal guidance Parents: Financial support & Personal Guidance
02 CUBI - Final Master Project Industrial Design
DESIGN PROBE
Proposal
15
Orientation Orientation on literature existing concept and media
18
Design considerations Some design considerations are made by intuitions, others have relation to earlier work.
TABLE OF CONTENTS
SEMESTER 2
SEMESTER 3
22
29
After the plans were presented to my fellow students and educators, the development of Cubi started. The biggest challenges were the communication between blocks, the electrical connection between blocks, and the written software for position-discovery.
Most time spend in this project was on programming of the interaction. In total there are three different scripts that make the interaction of the product work.
Technological development
Programming the interaction
TESTING
CONCLUSIONS
33
34
Findings and concusions All findings are catogarized and described. Here you can read about the observations made, and proposed usability improvements.
EXECUTIVE SUMMARY
T
his report describes the chronological design process and results of my 1,5-year Final Master Project (MSc) at Industrial Design, TU/e. You will read about the progress of my final master project and the creation of an intuitive, tangible programming tool for kids that familiarizes them with the basic concepts of coding. Through literature studies,
user tests, and design probes, this report examines how to fit a tangible programming tool into the educational environment. The first two tests explore how concepts of programming can be taught. The final test explores Cubi's usefulness for a group setting of 8 and 9 year olds. Furthermore, literature about existing tangible programming tools has been explored in this study, to support design
decisions and to present a vision of the future of programming in education. We can see a growing awareness in the media of the importance of programming education (Code.org 2014). But though many educators understand the importance of teaching programming at young age, they do not know how to teach this subject. Using Cubi that was created
Future steps What will I do after this project? Create better promotional material. Improve the robot, and usability of the blocks. Find investors for further development.
in this final master project, it can be concluded that programming can be taught, in a playful manner, to young girls and boys. However, the results of these tests are only an early indication of how Cubi can be used. Further testing and research is recommended to improve Cubi, and the way we teach children how to code.
Eindhoven 2015 - Cubi 03
INTRODUCTION
WHY CUBI, AN INTERACTIVE PROGRAMMING TOOL FOR CHILDREN, WAS CREATED - AND HOW IT FITS INTO SOCIETY.
04 CUBI - Final Master Project Industrial Design
CUBI Cubi is an intuitive, tangible programming tool that helps children explore the very basic concepts of programming that are needed to understand the variety of programming languages that exist.
T
Through spatial ordering of physical blocks that each have their own function and parameters, a program can be executed by a little robot. The design intention of Cubi was to make the tool highly intuitive, while providing many possibilities and giving the kids freedom in their programming experience. With Cubi, basic concepts (sequencing, variables, global and local settings, and loops) are explored without having to name these concepts. These concepts are represented by physical blocks; each block shows a symbolic representation of its functionality. Although the concepts of programming are symbolic, there is still a relation to visual and textual programming languages. This tool can be used as an introduction to the more complex programming languages.
Where did the idea come from?
Cubi was created over 1,5 years, as my final master project. In the beginning of the project, a proposal was written, which described how my chosen subjects fits my vision and identity as a designer. I have had a long-term interest in education and programming. My desire to combine these two passions led to an exploration process, where I studied the current tools for programming education. In the first weeks of the project, I explored several existing tools: Siftables, Cubelets, Scratch, and more. These tools taught me that education of abstract subjects like programming could taught to young children, but there is still room for improvement of tangible programming tools. In the first iterations of my project, I explored the possibilities of a tangible programming tool. Through a combination of several existing tangible programming tools, I created Cubi.
Eindhoven 2015 - Cubi 05
INTRODUCTION
Figure 1: piaget's theory of cognitive development . More info: http://www.simplypsychology.org/piaget.html
GOAL WHY HOW WHAT Cubi will be made available in primary schools as a tool for teachers to explain programming in an intuitive way. Not everyone needs coding skills, but learning how to think like a programmer can be useful in many disciplines (Shein 2014). The basics of Cubi can be explained through an instruction video or a demonstration. After that, children can explore freely and follow short assignments. New concepts of programming can be taught in parallel with math concepts. And, once the students have used Cubi to understand the basics of coding, they can move on to a more complex visual programming language.
06 CUBI - Final Master Project Industrial Design
Why everybody should learn to program at a young age My ultimate goal is for all children to become acquainted with the creative world of programming. From a young age, we are to communicate by reading and writing. In this new era of rapid technological improvements, children are exposed to a wide variety of technologies. They learn to interact with technology, but may be unaware of the creative possibilities they have if they learn to write code. This is a missed chance, as most people will not
learn programming at a later age (Meek 2012). By then, many people see coding as something too complex - or an activity for nerds. In order to change these attitudes, it would be good to teach programming the same way as we teach other subjects. When young children learn what is possible with programming, and learn the basic concepts, it is more likely that they will continue to learn coding later in life.
INTRODUCTION
What do we learn from programming? Programming is a different way of thinking; it is similar to solving a puzzle, playing chess, or building a piece of Ikea furniture. It requires you to break down a problem in small, simple steps, and to understand how one step leads to another (Summit 1995). The difference between programming and the above examples is that when you write code, you create the puzzle pieces yourself. It is a creative way of solving problems wherein multiple ways can lead to a solution. The combination of creativity and abstract thinking makes it an interesting course to include in curricula of primary and secondary schools as these skills are becoming more important in the 21st century.
The growing demand for programmers Through time computers have become so intuitive that even a one-year-old can swipe a photo. Of course intuitiveness is good for efficiency and pleasurable experiences with computers but in the past the chance that you had to do more on a programming level was much higher. Learning to program was a logical necessity if you wanted to get the full potential out of the computer. Now the new generation does not encounter this naturally. As the technological development is still growing, so is the need for programmers and creative problem solvers.
How programming could be introduced Cubi is meant to give children their very first introduction to programming. By simply ordering the physical blocks with your hands, a program is written; no previous knowledge or special skills are needed to get results from Cubi. Children explore the basic concepts of programming by playing with the physical blocks, but this is just the first of three steps in the learning process.
In the second step, children start to explore and build more complex programs within a visual programming language. In the third stage, they will learn to write entire programs by themselves in a textual language. Ideally, these three forms of programming (tangible, visual and textual) would be so integrated that moving from one level to the next would be possible within the same interface. Tangible blocks would influence visual blocks on a screen, which in turn would influence the syntax of a textual program. Each level would be more complex, and open up more possibilities. Visual and textual programming languages are already well developed, so I focused on tangible programming. The aim was to make a product which can be understood by 7-year-olds. Because Cubi is modular, more advanced function blocks can be introduced to older students.
How programming could be integrated in existing curricula We don't just learn math because it’s good to be able to calculate. Math also increases your capabilities for solving complex problems. The same applies to programming, in which a student learns to split up a problem into small, simple steps. With programming, there is never just one solution; it is a creative process in which different opportunities can be explored (Sweigart 2012). At basic levels, programming overlaps a lot with math. As students learn to count, they could also incorporate this into a program. The moment we learn about multiplication, the concept of a loop could be introduced. Once students learn simple algebra, ifstatements and variables can be introduced. Parallels in programming can be found for every mathematical concept. The beauty of programming is that mathematical concepts become visual, and can be experienced in the real world. This makes abstract problems much easier to understand. Every new math concept can become a new programming project.
Figure 2: Toddler with app Figure 3: IBM computer
In the past the chance that you had to do more on a programming level was much higher. Learning to program was a logical necessity if you wanted to get the full potential out of the computer. Eindhoven 2015 - Cubi 07
INTRODUCTION
Why are we not yet teaching programming in schools? Many teachers, at least in the Netherlands, do not have any programming background. Therefore, it is understandable that they do not have the necessary knowledge to teach programming concepts. Two things need to happen: teachers should learn the basics of programming through a training and tools like Cubi, and Scratch should be developed further to support teachers. If the tools provide the right practice, the teachers themselves can use these tools to learn programming and develop lessons with the tools.
In which order should students learn concepts of programming? There is a logical order to teach the basics of programming. Only a handful of concepts need to be understood in order to write a computer program; we already understand most of them intuitively and use them in our daily lives. For example: When it rains, you take an umbrella. All the different programming concepts we need are listed down here written down with simple examples as a guide for teachers who want to start teaching to code.
yy
A program is a set of instructions for a computer to execute •
yy
•
What is an execution?: Actually walking forward two meters
•
Dividing up instructions: "Taking a step" can be described as lifting your foot and putting it down in front of you. Computers are dumb and need very simple instructions.
A program is executed in a specific order. •
yy
What is an instruction?: "Walk two meters forwards"
Computers execute the instructions in the order they are given
Parameters
08 CUBI - Final Master Project Industrial Design
Figure 4: collage of explored programming environments
•
yy
•
(Delay) Stop the execution of instructions for a specified amount of time.
yy
(Loop) Repeat actions X amount of times: "take a step 10 times"
While: •
yy
This is a loop inside of another loop: "take 4 times 5 steps"
For example: "While the light is on, drive forward, if the light is off go to the next instruction."
Functions: "When I reach a function, execute all these actions:"
If something happens, execute this: "If it rains, I take an umbrella."
If /else •
yy
nested repetition
If •
yy
yy
Repetition •
yy
take my umbrella."
Waiting •
yy
Parameters specify the amount of repetition for a certain action. For example: "Walk 5 steps", or "Walk 10 meters".
If something happens, execute this, else do this: "If it rains I take an umbrella, otherwise I leave it at home"
nested if statements •
If this is true, and this is true as well, do this: "If it rains, and it is also windy, I take my raining jacket, otherwise if it only rains I
Figure 5: Bill Gates in video from hour of code
INTRODUCTION
affordances of tangible objects. More recently, Marshall et al, (2007) claimed that their tangible user interface (TUI) has great potential to support learning due to its “hands- on” nature. Also, a study of Horn, Crouser, and Bers (2011) indicates that tangible interfaces were preferred for early exploration, and graphical interfaces were best for subsequent “rapid prototyping”.
TANGIBLE PROGRAMMING: A THEORETICAL BACKGROUND AND ARGUMENTATION Tangible interfaces have a more inviting nature, which encourages participants to interact with them and explore the various types of available objects. There is probably not one best way of teaching programming. Teachers can help students explore the concepts of programming through play. Children can act out a program; one child can act like a computer and respond to others' small assignments (Instructor 2012). However, children eventually need to learn how to work within a programming environment. There already valuable visual programming languages, such as Scratch and Hopscotch. These programs are not good for beginners, because there are too many possibilities. Therefore, children spend more time learning the interface than learning the concepts of programming.
Research by Horn et al. (2009) and Wang et al. (2013) showed that tangible user interfaces result in more engagement and provide better opportunities for exploration than graphical programming interfaces. Tangible interfaces have a more inviting nature, which encourages participants to interact with them and explore the various types of available objects. A study by Zuckerman and Gal-Oz (2013) indicated that their users preferred tangible interfaces over graphical ones, though in terms of performance they were almost the same. They suggest that this might have to do with the fact that tangible user interfaces have the advantage of natural
In the research of (Sapounidis and Demetriadis 2013), it was indicated that a tangible interface was more attractive, especially to girls. It was easier for younger children to use, but older children who were more experienced with computers also considered the graphical system easier. Moreover, the research recorded instances where cooperation between the members of the team offered more opportunities for equal participation when using tangibles; however, the control over a graphical interface on a computer by one child seemed to reduce the interest of the other children involved. Also, TUI have a more embodied experience. The research of (Horn et al. 2009) suggests that embodied experi¬ences are a more efficient way of learning. Therefore, a tangible programming tool could be used to teach programming concepts to people who have no knowledge of programming concepts. Tangible programming tools have several advantages: yy
If the design is right, everybody will understand the form language of the physical tools, making interacting intuitive. Lessons can be based on programming concepts, rather than on using the interface (Hurtienne et al. 2007).
yy
As there is more sensory input, it is easier to form a mental picture of the abstract concepts (Processes and Know 2010).
yy
The teacher can control the pace
Eindhoven 2015 - Cubi 09
of learning by introducing new concepts when students are ready for it. yy
Teamwork is possible because participants can claim ownership of different pieces of the program. Discussion can take place of how construct a program. With a classical computer interface, only one student can be in control of the input (Speelpenning et al. 2011).
yy
Teachers with very little knowledge of programming can learn each concept themselves before introducing it to the children.
yy
A tangible user interface can be equally attractive for boys and girls (Zuckerman and Gal-Oz 2013).
yy
Rich interactions like shaking, squeezing, turning, etc. are possible with tangible programming tools. This may have more pedagogical advantages (Horn et al. 2012).
Tangible user interfaces have been developed more and more in recent years. However, few are available because they are still in early stages of development. Also, not all functions are crystalized yet. I studied several existing tangible projects to find potential improvements to Cubi. The research of (Begel 1996) suggested a desirable feature for tangible programming interfaces. When the program was executed, each block would highlight in turn. This way, you could debug the program without having to try it out physically. Tangible programming tools have limitations of interaction (Horn et al. 2009). Also, they are technically challenging, and are not always fully functional (McNerney 2000). One of the conclusions of E-block was that the blocks did not give enough feedback for debugging. The researchers recommended a system that would be highly synchronous to the child’s latest manipulation (Wang et al. 2013). Tangible programming interfaces are technically challenging and may not always work. However, with the right technological development, these problems can be overcome.
Why now? Around the time I started this project, several items in the media assured me of the importance of developing Cubi. Big companies like Google and Facebook have stated the importance of programming in education through their endorsement of the "Hour of Code" project by code.org. Although there is currently no shortage of people who know about programming, there is a shortage
10 CUBI - Final Master Project Industrial Design Figure 6: Collage of existing tangible programming tools
The goal of Cubi was to focus on the improvements suggested by these previous studies, such as live debugging, modularity, and form language.
Figure 7: President Barack obama endorsing code.org learning how to code.
in well-educated programmers. Most programmers learned programming through self-study, and lack a thorough grounding in the basics (Reading 2014). In order to get these good programmers the intention of Hour of code is to give everybody an introduction into coding. The more people who get a proper introduction the higher the chance that people who like programming will continue and spend the hours needed to learn a complete programming language.
Research opportunities Over the past two decades, numerous tangible user interfaces have been developed; they have been tested to see if they can outperform a graphical interface. In research about these tools researchers looked at performance, ease of use, learning rate, recall, task completion, time, satisfaction, enjoyment, and engagement. The study of (Zuckerman and Gal-Oz 2013) indicated that further research was needed to find out which performed better: a graphical user interface (GUI) or a tangible user interface (TUI). In a study
of 58 participants, they tested two systems (GUI and TUI) which were designed to look and function the same. They concluded that GUIs and TUIs perform equally well, but that students strongly preferred the TUIs. The goal of Cubi was to focus on the improvements suggested by these previous studies, such as live debugging, modularity, and form language. Several design aspects of existing tangible user interfaces were combined into the Cubi product, which was tested in a classroom situation. Group dynamics and usability were little studied in similar TUI studies, so these aspects were investigated further in my project. When Cubi was tested in a classroom situation, it was shown that the modality of Cubi made it easy to control the learning curve. Children liked to play with Cubi and worked together in pairs or groups of four. For 45 minutes, they managed to try out several programming concepts. However, the testing-time was short, and technical issues accrued. These results should be seen as an indication of the need for future studies.
Eindhoven 2015 - Cubi 11
HIGH COMPLEXITY This grouping was the starting point for the rest of the project. The diagonal line from bottom left to top right can be seen as a student's learning path through programming-study. The further you follow this line, the more functions are added and the more knowledge is needed.
Tangible programming bricks SCRATCH
CUBI SIFTEO
VISUAL
TANGABLE
QUETZAL T_PROROB
CODE.ORG
T-MAZE
HOPSCOTCH DR. WAGON
TERN
DAISY THE DINOSAUR PRIMO
Primo(Lomas 2013) , Dr. Wagon(Chawla, Sandes, and Chiou 2012) , Tern(Horn et al. 2009), T_proRob(Sapounidis and Demetriadis 2013), T-Maze (Wang, Zhang, and Wang 2011), Quetzal (Horn and Jacob 2007), Daisy the Dinosaur (Flannery et al. 2013), Hopscotch (Lomas 2014), Code.org (Russell 2014), Scratch(Resnick et al. 2009), LogoBlocks (Begel 1996), Lego Mindstorms (Shaer 2009), Alice (Cooper, Dann, and Pausch 2000), Turtle Academy (http://turtleacademy.com/ 2014), CodeMonster Crunchzilla (Linden 2012), Hackety Hack (Finley 2011), Codecademy (Magid 2014)
CODECADEMY ALICE LEGO MINDSTORMS
HACKETY LOGOBLOCKS
CRUNCHZILLA
VISUAL
TEXTUAL
TURTLE
LOW COMPLEXITY
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 1
First exploration for creating a tangible programming tool.
ITERATIVE DESIGN DEVELOPMENT OF CUBI Every semester, a combination of activities like literature studies, prototyping, user studies, expert meetings, and discussions took place.
Iterative development Over the one-and-a-half year duration of this project, an iterative design approach was followed. Every semester, a combination of activities like literature studies, prototyping, user studies, expert meetings, and discussions took place. At each stage, I reflected on the process to set new goals and adjust my ambitions. Because I very much wanted to create a working prototype, we decided to add an
14 CUBI - Final Master Project Industrial Design
extra semester to this project, so I could reach all of my goals.
SEMESTER 1 The semester started with writing a proposal to set the boundaries of my project. Later this semester, this was defined into a concrete concept and physical and visual mockups were created.
SEMESTER 1- ITERATIVE DESIGN DEVELOPMENT OF CUBI
PROPOSAL
In preparation for the final master project, a proposal was written based on my explorations of existing tangible programming tools. A first design probe was made to explore the solution space and to define goals for the rest of the project.
Exploration through video and sketching In the first three weeks of this semester, I started pursuing the option of using Siftables as a base for a tangible programming tool. Siftalble or Sifteo cubes appeared to be a suitable tangible and visual tool that could be used as an input for an animation or a robot. I decided to make a mock up movie of our concepts, using this tool. Exploring existing TUI studies gave me information about the form that my tangible programming interface should take. All the functions should be visible, like puzzle pieces, to create an intuitive program. To achieve this with Siftables, a large set would have to be ordered or every block would have to have multiple functions. I also noticed that the screens were too small to keep an overview of a whole program.
Design decisions: yy
All functions should be visible; have only one function per block.
yy
Each block should be large enough for the students to quickly read the symbols and immediately understand the function of each block.
Initial Literature exploration The proposal for this project discussed why programming education is an interesting pursuit, and why it's interesting to study more embodied interactions. A short exploration into the existing solu-
tion space motivated me to continue the project. Many different visual and tangible programming solutions already exist. The second design iteration of my project, this semester, points out what the strengths and weaknesses of these solutions are, and how Cubi could improve on earlier TUIs.
Orientation on literature existing concept and media The initial literature exploration in the proposal provided a lot of information about one existing tangible tool; the second phase explored several more programming tools: tangible, visual, and textual. Pictures of the different tools were printed out and grouped into clusters. On the previous two pages, you can see the results of these clusters. On the X axis, the programming tools are divided into groups: physical, visual, and textual. On the Y axis, they are listed by complexity. This grouping was the starting point for the rest of the project. The diagonal line from bottom left to top right can be seen as a student's learning path through programming-study. The further you follow this line, the more functions are added and the more knowledge is needed. Most tangible programming tools are still in their prototyping phase. The only one that is actually on the market is Primo, which teaches only the very basics of programming. Cubi is a more complex tangible interface with a highly intuitive and interactive interface. Cubi is highly inspired by and builds upon the existing tools: Dr. Wagon, T-Maze, and Tern. It is designed to be followed up by Scratch. Further investigation is needed to see if starting with a tangible programming tool to learn programming is indeed the best way to go. One thing that we can say for sure is that every tool provides its own learning experience. Every person has their own learning style, but in general you want to go from less complex to more complex.
First exploration for creating a tangible programming tool.
Most tangible programming tools are still in their prototyping phase.
Eindhoven 2015 - Cubi 15
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 1
CONNECTING TANGIBLE, VISUAL AND TEXTUAL PROGRAMMING
It is important to connect the different levels of programming tools. As the tangible programming world is the least explored of these, it was a logical choice to go in this direction.
W
hen we connect different layers of programming tools, it is possible to go from a physical input, to a visual input, to a textual one. If all the layers of programming tools were intertwined, going up and down in complexity, would teach the student a lot. Completing each layer of complexity gives a moment for reflection. For example, when the intuitive tangible blocks are repositioned into a program, these positions are automatically copied into a visual programming language. This provides options, and a moment for the student to reflect on what they have created. The more freedom for growth such a system
would have, the more freedom students would have to follow their own learning path. Going up and down in these stages is an interesting thing to investigate because it is not done yet. Will a student understand his code if he sees a visual representation of the tangible world? Or a textual representation of the visual world? Can certain programming concepts be explained by first letting the programmer experience (tangible) after that conceptualize (visual) and after that create completely new programs themselves (textual)? Although building such a system would be out of the
16 CUBI - Final Master Project Industrial Design
possibilities of this final master project it is important to see how Cubi can fit in a bigger picture.
Media orientation In addition to literature studies, I started discussions in several Dutch Linked-in groups, to get the opinions of teachers on the subject of programming (Tijmen van Gurp 2013). Not everyone agreed that programming should be a compulsory course. The opponents' arguments were that it would take too much time, and that teachers are not educated to teach that
course. The teachers referred to 21st century skills and “media wisdom� as necessary subjects for primary and secondary school students. It was pointed out that the skills could be taught in conjunction with similar subjects, but that it was impossible to teach programming in classes as large as 30 students.
SEMESTER 1- ITERATIVE DESIGN DEVELOPMENT OF CUBI
PRIMO AND DR. WAGON
The tangible programming tools "Primo" and "Dr. Wagon" were closest to what was intended with Cubi, therefore it is important to look at why these tools are good, and what options are still missing. Primo is a tool for children from the ages of 4 to 7 years old. Primo is inspired by classic puzzle toys. By placing wooden tiles on a board, the children can give sequential assignments to a little robot. They also have the opportunity to write a function. Dr. Wagon also controls a robot, and is more similar to Cubi than Primo. Through blocks that can be snapped together, a program is written that controls the robot. It handles basic if-statements and loops, but not functions. These tools inspired me during the development of Cubi. Both Primo and Dr. Wagon are fairly simple in complexity. This is a good thing, because you don’t need to learn much to use them. However, they do not allow much room for creativity. I aimed to improve on these tools, creating a tangible interface that gives students more control, but is still intuitive. Figure 8: Left Cubi, left Dr. Wagon
Eindhoven 2015 - Cubi 17
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 1
DESIGN CONSIDERATIONS With the existing products in mind, a tangible probe and visualization of a programming tool were created to explore in greater depth how Cubi should look and function. These probes were used to get feedback, and for simple cognitive tests to see if the visualized concepts were being understood.
Icons: The actions that the blocks represent should be visualized iconically, to make it more intuitive. The blocks should be universal so that they can be used by all students, regardless of their spoken language.
Size of the blocks:
Debugging:
An unexpected result:
The blocks must not be too small. Larger blocks are easier to grasp, and leave more room for iconic representation on the top of the blocks.
The blocks will provide visual feedback to the user. When a block is executed, it lights up. When a block is misplaced, an error indication will appear.
Sometimes, children just play with the connectable coding blocks as if they were regular blocks. Without a clear assignment or a programming goal, these modular tools may not facilitate learning.
Output of the program: The output does not necessarily have to be a robot; it could also be an animation on a screen. But controlling a little robot is more playful and inviting than an animation on screen.
18 CUBI - Final Master Project Industrial Design
SEMESTER 1- ITERATIVE DESIGN DEVELOPMENT OF CUBI
Form follows function: Tangible tools can be used as an introduction to existing visual and textual languages. Therefore, their form factors should follow higher programming languages. Blocks that have the same actions will have the same colors. Blocks that belong with each other, such as "if" and "end if", will be connected by a string or with light feedback.
Modularity: The tangible programming interface may not give enough options; the maximum complexity of the program can be reached too quickly. Visual programming provides many more programming options than tangible programming can. Adding more blocks can allow for more functions, but this is expensive. If the expensive part of the block were interchangeable with modular pieces that represent other functions, the product could become bigger.
Design probe The wooden blocks were the first physical tryouts for making the actual system, no electronics were incorporated yet. The physical mockup was helpful in getting rich feedback, providing new opportunities, and creating design specifications for a new design iteration. Next to the wooden blocks, a graphical story line was created to explore the possibilities of this tangible programming tool. Eindhoven 2015 - Cubi 19
Top left: sketch of the robot, Top right: 3D sketch robot, bottem left: construction plaform for the motors, bottem right: Cubi in its final form
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 2
SEMESTER 2 TECHNOLOGICAL DEVELOPMENT
Atmega328P with pogopins and led connected
When the stage was set for this concept, the creation process could begin. This chapter explains the technical challenges and the design decisions I made for Cubi. 22 CUBI - Final Master Project Industrial Design
A
fter the plans were presented to my fellow students and educators, the development of Cubi started. The biggest challenges were the communication between blocks, the electrical connection between blocks, and the written software for position-discovery.
Communication protocol: In order to have a modular system, each piece needs to communicate its own unique ID to a master block. I examined several options, and decided to use the Atmega 328P, on an Arduino mini Pro, as this chip has on-board functionality for I2C. However, this is not the most stable
SEMESTER 2- ITERATIVE DESIGN DEVELOPMENT OF CUBI
From top left to bottem right: Atmega 328P, Pogo pins, RGB LED, Setup to test I2C connection, Pogo Pins see trough, Magsafe connector apple
way of communication over distances larger than one meter. Other options were also explored, but these required extra hardware which would make the production process more expensive and time-consuming. A setup was made where a master could send and request data from its slaves. It also had the capability of broadcasting messages to all slaves, simultaneously.
Ordering and finding parts Earlier studies using modular block TUIs had problems with the connections (Zuckerman and Gal-Oz 2013). I researched high-end connections, looking for solid, proven technologies. The connections I chose use the same technology as Magsafe connectors used by Apple.
Magsafe connectors use small springloaded golden pins (pogo pins), that connect precisely at the right spot because of a magnet. These pins were especially hard to acquire, because of high prices for low quantities and long waiting times for production. All other parts: Arduino’s, magnets, wires, headers, breadboards, and parts for the robot were found at web shops.
Eindhoven 2015 - Cubi 23
INSIGHTS FROM LESSONS SCRATCH PRIMARY SCHOOL I
wanted to gain a better understanding of children’s programming skill and to learn how the existing TUIs worked. I gave a lesson in Scratch to two groups of primary school children: a group of 7 to 8-year-olds, and a group of 9 to 11-year-olds. In the first group, some students had never heard of programming before; others knew that it was had something to do with computers and some shouted things like "downloading", "installing", etc. A short role-playing session with the teacher familiarized the students with the concept of instructions, and especially how to split up instructions. After this introduction, it was time for Scratch. The first group worked in pairs on the computer; the second group worked individually. I observed the following: yy
Only one student could control the mouse; the other student gave instructions or waited for their turn.
yy
They all seemed to like it, but not always for the same reasons.
yy
There was a noticeable difference between boys and girls: it appeared that most girls enjoyed drawing puppets that they could animate with the program more than the programming itself. Guys were also interested in the characters but were also more involved in coding although most guys just copied the same code over and over, because they did not know what all the other functions did.
yy
Some students created a storyline; others created a more random animation.
24 CUBI - Final Master Project Industrial Design
Some students created a storyline; others created a more random animation.
A teacher, or some sort of tutorial interface, was needed to teach actual programing concepts. yy
When new concepts were introduced, the students all wanted to know how they worked. But learning new concepts without instruction seemed too difficult for them. Scratch did not provide enough guidance for an intuitive learning process within the interface.
The students all had fun, but it's hard to say if they actually learned any programming concepts. The children needed clear, step by step instructions in order to make something. It might be that there were too many options for these children. The second group of children, aged 9 to 11, started with a step-by-step version of Scratch, wherein they had to use new concepts each level. The children all succeeded, but some children got annoyed
because there was mutual competition. Some were simply faster than others which made others feel uncomfortable and insecure. A process wherein students could follow a tutorial together and collaborate on the solution would be a desired solution. A teacher, or some sort of tutorial interface, was needed to teach actual programing concepts. However, because only one lesson was observed, it's not possible to know what would happen over multiple courses. Perhaps, over time, the students would become comfortable with Scratch, and begin to work independently. For explanation of concepts, the teacher used a Digi-board. Most of the lessontime was spent explaining the interface, instead of teaching programming concepts. This observation motivated me to create a tangible interface that could help the teacher explain programming concepts via a hands on approach, instead of by a classic teaching style where the students sit and listen to the teacher.
Eindhoven 2015 - Cubi 25
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 2
DISCOVERY PROTOCOL BLOCKS To make the modular setup work, five lines between each block were needed: two for power (red and black), two for data (blue and white), and one for a digital handshake (orange). One of the most challenging parts was the programming of the discovery protocol. A block can exist in a variety of positions; how could the robot know in the order of the blocks? This is where the orange “handshake” wire comes in. The handshake exists only between two blocks and the software written can therefore use this connection to establish a chain reaction in order to find out who is where. Simply put, this is how it worked: 1. The master sends a handshake over its pulse line. 2. Only one of the slaves, the neighbor of the master, receives this, and sends its ID to the master in response. 3. The master then sends a message to
26 CUBI - Final Master Project Industrial Design
this ID; this message makes this slave send a handshake pulse to the next slave. 4. This will result in the second slave sending its ID to the master. Global and local variables and functions are important programming concepts. "Global" means that something is accessible everywhere, and "local" refers only to one instance. With Cubi this can be achieved by placing blocks above, under, and next to each other. This made the code a bit more complicated, but was, in theory, the same as the given example. After the code was complete, a test setup was built with twenty Arduino’s connected to each other. This made it possible to make all the timings right and test all the connections.
Design and assembly blocks The blocks were designed in the program, "Google SketchUp". 3D models were exported to vector graphics, which were in turn used to laser cut the parts of each block. Through several iterations, the connections were improved and tested. The blocks were designed in such a way that their cover could be removed. This allowed me to focus on the technical challenges; the front panel could always be redesigned in the end. The receiving parts of the pins were made by hand from copper plates. The blocks were glued together first; later, they were assembled with the electronics.
Defining goals Although there was still some time left, it was not enough to finish and test the product as intended. Scaling down my ambition was not an option, because adding just another unfinished tangible programming tool to the existing ones would not be satisfying. We chose to add an extra semester at this point, to finish the coding and assembly for a full, working product.
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 3
SEMESTER 3 T
his semester was spent finishing and evaluating the product. I spent most of this time on assembly and software development. Also, a small evaluation was done with a paper prototype to get insights from end-users. A final test was done with the working product with 5 groups of 4 students. This test gave insights in the usability of the product and raised questions for further testing. Continuation assembly and design robot While the product was being assembled, a few extra improvements were made. A RGB LED was added to each block for debugging purposes, and a shortcut protection was implemented. I also redesigned the robot. Through several sketches, a simpler form was established. Improved motors and wheels were implemented into this new robot. Through several iterations, a 3D model for the robot was created. This allowed the parts to be cut out by the laser cutter.
28 CUBI - Final Master Project Industrial Design
SEMESTER 3- ITERATIVE DESIGN DEVELOPMENT OF CUBI
Test with paper prototype During the assembly phase, a small user study with a paper prototype gave some extra information for the design of the blocks. This test used small pieces of paper with written instructions. These instructions were something like "walk two steps forward, turn a quarter". When a more complex set of instructions, like “repeat” was introduced, some explanation was needed. The repeat instructions consisted of 2 papers, one saying "start repeat", and the other one saying "stop repeat"; all of the papers in between these had to be repeated. It appeared that this was a difficult concept for sevenyear-olds to grasp. They did not understand that everything between these papers should be repeated. This implicated that maybe text or symbolic language is not enough. Perhaps repeat blocks, which belong together, should be explained verbally or symbolized physically. I considered connecting the blocks with a little string. Although this might make the link between the blocks clearer, the option of light feedback was more appealing, due to my time-constraints.
Programming the interaction I spent most of my time on this project programming the interaction of the product. In total, there are three different scripts that make the interaction between the blocks and robot work. All the function blocks have the “slave” code. The one block that powers them all is the “master block”. This block also sends the position of the blocks wirelessly to the robot. A good separation of code and functionality made this an interesting project to develop. The code for the robot was especially challenging. A string of comma-separated numbers, that represented all the different blocks, needed to be translated into a program for the robot to execute. In total, more than 8000 words of code were
typed. Although code quantity does not say that much about quality, it still gives a good indication of how much work I did on software development. The code for the robot had to receive and order all incoming data, assign functions to the data, combine functions, and execute functions. Besides that, the robot gave updates about where it was in the program, so that the blocks could light up accordingly.
Redesign front panels blocks Earlier designs of the blocks' front panels had small windows for the LEDs to shine through. But it was better to make the whole panel translucent, so that it would look more uniform. Blocks with the same function received the same color indication in the icons, so that it would be easy to make a distinction between the blocks. The icons chosen were as universal as possible, without text, so that interaction was based on recognition of form language rather than reading. Also, a small gap and bulge was added to the front panel so that they would fit in each other like a jigsaw puzzle. In this way, it was clear what the top and bottom of the panels were. It also gave an indication of which blocks would fit next to each other and which blocks wouldn't. The starting block was also designed. This block received a play button and a loop button. When these buttons were pressed, a light indicated that the program was send to the robot, which then in turn would execute the commands.
Top: example of written code for this project. Bottem: Redesign front pannels of blocks.
This implicated that maybe text or symbolic language is not enough. Perhaps repeat blocks, which belong together, should be explained verbally or symbolized physically. Eindhoven 2015 - Cubi 29
TEST WITH CHILDREN 30 CUBI - Final Master Project Industrial Design
In the test, the teacher plays an important role in guiding the learning process.
For the evaluation of the product, a test was executed with five groups of four children between 8 and 9 years old. Each test was 45 minutes long, with an introduction and explanation phase of 30 minutes. In this first phase, blocks were introduced and explained. After that, there was 15 minutes of time for students to explore possibilities on their own. The goal of the test was to find usability improvements, observe group interaction, most of all to see if this was something that the children liked. From previous research, it is known that tangible user interfaces do not perform better or worse than visual user interfaces (Zuckerman and Gal-Oz 2013). However, they noticed a strong student preference for tangible user interfaces. Also, in group settings, tangible interfaces outperformed graphical interfaces. Little is known about how tangible user interfaces work in a group setting; investigating this was an interesting aspect of my research. Cubi can be manipulated by multiple people at the same time. With video analysis, verbal and nonverbal communication and collaboration can be studied. Working in a group is advantageous, because the setting is more natural for children and they may forget that it’s a test. In the test, the teacher plays an important role in guiding the learning process. The blocks are introduced one by one; after every explanation there is time to explore and reflect. By giving the students little assignments, the teacher can know if a con-
Eindhoven 2015 - Cubi 31
ITERATIVE DESIGN DEVELOPMENT OF CUBI - SEMESTER 3
cept is understood and if new concepts can be introduced. After this introduction phase, time was allowed for free exploration without the teacher's involvement. Findings, conclusions, and improvements in usability During the tests, there were many problems; the videos are not properly encoded. My findings are therefore somewhat subjective and only based on observation. They should be seen as starting-points for further investigation.
Technical errors During the tests there were problems with the wireless transmission; it seemed that the link between the blocks and the robot was sometimes lost. The solution was to give the robot more power by hooking it up to a computer. As this happened several times during the test, the results are inconclusive and future studies will have to indicate if the found findings are correct.
Self-explanatory The goal of Cubi was to be as self-explanatory as possible, soon during the test it was noticed that guidance in their discovery process was needed. That said, little explanation was needed to explain how the blocks could be connected and how to send new assignments to the robot. Most iconic representations were easily understood, but what the position of the knob meant was not always clear to the children. A knob more to the + side meant drive "longer", but this was confused with the concept of "faster". A bi-directional slider might be easier to understand, as pushing the slider left would mean to turn more to the left. This would make the interaction more "one-to-one". Another option would be to separate the time-todrive and the direction into two blocks.
Play versus control Once the children had their explanation, and were given the freedom to create whatever they wanted, the enthusiasm of playing with the blocks and robot overruled a sense of planning and logic reasoning. Random programs were created to see what the robot did. Although when
32 CUBI - Final Master Project Industrial Design
assignments were given, like let the robot drive in a square, they were motivated to solve this task.
Light feedback, and form follows function It was clear to the children when the blocks were connected in the right way, because only then would there be a light indication. The physical shape of the blocks only allowed that them to be connected in one way. This design future proved itself to be very helpful. The blocks also lit up when the program was executed. However this was not seen in the test, because the robot was positioned behind the students, and they could not see the robot and the blocks simultaneously. Future test should have a different placement of blocks and robot to see if the light feedback helps with understanding the placed code.
Collaboration During the tests, all of the students interacted differently with the product. Some
just observed what others did and sometimes everyone collaborated. Collaboration in pairs, using the same set of blocks also occurred; the students took turns executing their sets of blocks. The modality of the tool made it possible to actively participate or just observe. It would be interesting be to investigate what the students learned from each other while working with Cubi.
SEMESTER 3- ITERATIVE DESIGN DEVELOPMENT OF CUBI
CONCLUSIONS AND FUTURE WORK Through several iterations, literature studies, prototyping, and testing, a tangible programming tool called "Cubi" was created and tested with 5 groups of 4 children. The test gave good indications about the usability and opportunities for further research within the field of tangible interfaces. However, the number of participants and technical problems during the test made it impossible to state these observations as true. Further tests are needed, along with improvements in the interface, to draw conclusions about the effectiveness of a tangible programming tool.
Age The eight and nine year-olds may have been too young for these blocks, as some concepts like loops were hard for them to understand. That being said, there are a lot of possible points of improvements in both hardware and software. It is hard to say if this confusion was a function of age or usability or both.
Duration of the test The duration of the test was only 45 minutes; too many functions were explained in this short time. A test over several lessons would better indicate if all of the intended functions were understood.
Start block The "play" button on the start block worked very well, but there was no possibility of stopping the robot during its execution. It would be nice if next to the start button was also a stop button. Also, auditory feedback could be added to the start block or in the robot; in this way, feedback could be given in a situation
where there is no teacher.
Loop blocks It was not clear that the two loop blocks belonged to each other; extra explanation by the teacher was needed to explain this. Different physical forms could be explored in order to link the two blocks together. Also more light feedback within the blocks may help: all the blocks between the two loop-blocks could light up.
Orientation The children had difficulty with orientation. The robot did not face always the same way as they did, and sending it another direction was hard to do. Therefore, a graphical interface with the same tangible tool would be easier, as the output could be always in front of them.
The important observation was that Cubi worked well and the children liked it. They remained engaged with Cubi over a period of 45 minutes. This was also noted in the research of (Horn et al. 2012). From the teachers' perspective, Cubi gave them control over the learning process by allowing them to gradually introduce function blocks. The children collaborated and helped each other to fulfill assignments. Clear assignments were needed to transition students from playing with the blocks to a problem-solving mode. Cubi seemed to support different learning styles: some children learned by trial and error, while some were quiet and thought through the steps that needed to be taken. The collaboration between the children meant that they all stayed involved during the test; little motivation was needed from the teacher to get them to try new things. Although Cubi had promising results, in the overall picture a lot of the blocks can be improved in their visual and form language. Also, technological improvements have to be made so that connections always work well. Using the blocks for a digital output, instead of the robot, is a possibility worth studying. This would have the advantage that the output is near the blocks, and that it is less expensive. That said the robot added a lot of fun into the lesson which might be
Eindhoven 2015 - Cubi 33
lost with an on screen animation. A better controlled test setup is needed to prove that a tangible programming tool is a good tool for the introduction of programming. Many interaction aspects can be improved, but this would require more money and time. My plan is to find the most important research questions and provide more information with Cubi; more iterations of improvements are needed to come closer to a finished product. Because of the modularity of the blocks' front panels, most iterations can be done with existing technology. New ways of input, sign, and form language can be explored before improvements are made on the technical side.
FUTURE STEPS After a better set-up test, it is important to find partners for this project; to reach them, I am creating better promotional materials. Hour of code, Raspberry Pi, and Lego are potential partners, because they have already shown an interest in teaching programming through their products. Also, a better worked-out technical model will point out the cost of each module. The main target market will be primary schools. A set of modules will probably have a price of around 500 euro’s. This depends on the materials used and the output device. A digital animated output, instead of a robot, might be cheaper; but maybe less fun for the children. Further exploration is needed to see how this product could fit into secondary schools. A closer collaboration with MIT's Scratch would be beneficial; perhaps the two products could work together. It is possible to find investors that have an interest in educating youth in new technologies, like Facebook, Google, ASML, Gates Foundation etc. For now, all options are open, and all suggestions are welcome.
REFERENCES
REFERENCES Begel, Andrew. 1996. “LogoBlocks: A Graphical Programming Language for Interacting with the World.” Electrical Engineering and Computer Science Department, MIT, Boston, MA. Retrieved January 12, 2015 Chawla, Kunal, Alfredo Sandes, and Megan Chiou. 2012. “Dr . Wagon : Making Programming Tangible.” 1–23. Code.org. 2014. “Join the Largest Learning Event in History.” Retrieved January 15, 2015 (http://hourofcode.com/nl/en). Cooper, Stephen, Wanda Dann, and Randy Pausch. 2000. “Alice: A 3-D Tool for Introductory Programming Concepts.” Journal of Computing Sciences in Colleges 15:107–16. Retrieved (http://dl.acm.org/citation.cfm?id=364161). Finley, Klint. 2011. “Learn to Program with Hackety Hack ReadWrite.” Retrieved January 18, 2015 (http://readwrite. com/2011/01/15/learn-to-program-with-hackety). Flannery, Louise P. et al. 2013. “Designing ScratchJr.” Pp. 1–10 in Proceedings of the 12th International Conference on Interaction Design and Children - IDC ’13. New York, New York, USA: ACM Press. Retrieved January 18, 2015 (http://dl.acm. org/citation.cfm?id=2485760.2485785). Horn, Michael S., R. Jordan Crouser, and Marina U. Bers. 2012. “Tangible Interaction and Learning: The Case for a Hybrid Approach.” Personal and Ubiquitous Computing 16(4):379– 89. Retrieved August 10, 2014 (http://link.springer. com/10.1007/s00779-011-0404-2). Horn, Michael S., and Robert J. K. Jacob. 2007. “Designing Tangible Programming Languages for Classroom Use.” Proceedings of the 1st international conference on Tangible and embedded interaction (TEI ’07) 159–62. Retrieved (http:// dl.acm.org/citation.cfm?id=1227003). Horn, Michael S., Erin Treacy Solovey, R. Jordan Crouser, and Robert J. K. Jacob. 2009. “Comparing the Use of Tangible and Graphical Programming Languages for Informal Science Education.” Proceedings of the 27th international conference on Human factors in computing systems CHI 09 32:975. Retrieved January 12, 2015 (http://portal.acm.org/ citation.cfm?doid=1518701.1518851). http://turtleacademy.com/. 2014. “About Turtle Academy.” Retrieved January 18, 2015 (http://turtleacademy.com/project/ doc/en). Hurtienne, J., J. Hurtienne, J. H. Israel, and J. H. Israel. 2007. “Im-
36 CUBI - Final Master Project Industrial Design
age Schemas and Their Metaphorical Extensions – Intuitive Patterns for Tangible Interaction.” Pp. 127–34 in Proceedings of the 1st international conference on Tangible and embedded interaction. New York, New York, USA: ACM Press. Retrieved January 1, 2015 (http://dl.acm.org/citation. cfm?id=1226969.1226996). Instructor, Sessional. 2012. “PhD Student in the Department of Computer Science TA and Sessional Instructor Computer Science 1026 and 1027 – Computer Science Fundamentals I and II.” Retrieved January 15, 2015 (http://scholar.google. com/scholar?hl=en&btnG=Search&q=intitle:No+Title#0). Linden, Greg. 2012. “Geeking with Greg: Code Monster and Teaching Programming to Kids.” Retrieved January 18, 2015 (http://glinden.blogspot.nl/2012/09/code-monster-andteaching-programming.html). Lomas, Natasha. 2013. “Primo Is An Arduino Robot That Teaches Kids Programming Logic Through Play | TechCrunch.” Retrieved January 18, 2015 (http://techcrunch. com/2013/11/24/primo/). Lomas, Natasha. 2014. “Hopscotch, An iPad App That Helps Kids Learn To Code, Raises $1.2M | TechCrunch.” Retrieved January 18, 2015 (http://techcrunch.com/2014/05/08/ hopscotch-seed/). Magid, Larry. 2014. “Codecademy: From Zero Experience To A Tech Job In Three Months.” Retrieved January 18, 2015 (http://www.forbes.com/sites/larrymagid/2014/11/07/ codeacademy-aims-to-take-future-tech-workers-from-0-toemployed-in-3-months/). McNerney, Timothy S. 2000. “Tangible Programming Bricks : An Approach to Making Programming Accessible to Everyone.” Media (2000). Retrieved January 12, 2015 (http://llk.media. mit.edu/papers/archive/mcnerney-sm-thesis.pdf). Meek, Teresa. 2012. “Math Nerds vs. Code Monkeys: Should Computer Science Classes Be More Practical?” Retrieved January 15, 2015 (http://blog.smartbear.com/careers/mathnerds-vs-code-monkeys-should-computer-science-classesbe-more-practical/). Processes, Memory, and Did You Know. 2010. “Memory Encoding - Memory Processes - The Human Memory.” 1–2. Retrieved January 15, 2015 (http://www.human-memory. net/processes_encoding.html).
REFERENCES
Reading, University of. 2014. “Why Is There a Shortage of Good Programmers? - FutureLearn.” Retrieved January 16, 2015 (https://about.futurelearn.com/blog/shortage-of-programmers/). Resnick, Mitchel et al. 2009. “Scratch: Programming for All.” Communications of the ACM. Rogers, Y. 2007. “Do Tangible Interfaces Enhance Learning?” … of the 1st international conference on Tangible and … 15–17. Retrieved January 12, 2015 (http://discovery.ucl. ac.uk/1338833/). Russell, Kyle. 2014. “Code.org Launches Code Studio, A Toolset And Curriculum For Teaching Kids Programming | TechCrunch.” Retrieved January 18, 2015 (http://techcrunch. com/2014/09/11/code-org-launches-code-studio-a-toolsetand-curriculum-for-teaching-kids-programming/). Sapounidis, Theodosios, and Stavros Demetriadis. 2013. “Tangible versus Graphical User Interfaces for Robot Programming: Exploring Cross-Age Children’s Preferences.” Personal and Ubiquitous Computing 17(8):1775–86. Retrieved September 9, 2014 (http://link.springer.com/10.1007/s00779013-0641-7). Shaer, Orit. 2009. “Tangible User Interfaces: Past, Present, and Future Directions.” Foundations and Trends® in Human– Computer Interaction 3(1-2):1–137. Retrieved July 23, 2014 (http://www.nowpublishers.com/product.aspx?product=HCI &doi=1100000026).
Sweigart, Al. 2012. “‘How Much Math Do I Need to Know to Program?’ Not That Much, Actually. | The ‘Invent with Python’ Blog.” Retrieved January 15, 2015 (http://inventwithpython. com/blog/2012/03/18/how-much-math-do-i-need-to-knowto-program-not-that-much-actually/). Tijmen van Gurp. 2013. “Programmeren Een Verplicht Vak Op Basisschool | LinkedIn.” Retrieved January 17, 2015 (https:// www.linkedin.com/groups/Programmeren-een-verplichtvak-op-72298.S.5792716499340775424?trk=groups_most_ popular-0-b-ttl&goback=%2Egmp_72298). Wang, D., Cheng Zhang, and Hongan Wang. 2011. “T-Maze: A Tangible Programming Tool for Children.” … on Interaction Design and Children 127–35. Retrieved January 12, 2015 (http://dl.acm.org/citation.cfm?id=1999045). Wang, Danli, Yang Zhang, and Shengyong Chen. 2013. “E-Block: A Tangible Programming Tool with Graphical Blocks.” Mathematical Problems in Engineering 2013. Retrieved January 12, 2015 (http://www.hindawi.com/journals/mpe/ aip/598547/). Zuckerman, Oren, and Ayelet Gal-Oz. 2013. “To TUI or Not to TUI: Evaluating Performance and Preference in Tangible vs. Graphical User Interfaces.” International Journal of Human Computer Studies 71(7-8):803–20. Retrieved September 11, 2014 (http://linkinghub.elsevier.com/retrieve/pii/ S1071581913000438).
Shein, Esther. 2014. “Should Everybody Learn to Code?” Communications of the ACM 57(2):16–18. Retrieved September 11, 2014 (http://dl.acm.org/citation. cfm?doid=2556647.2557447). Speelpenning, Tess, Alissa N. Antle, Tanja Doering, and Elise Van Den Hoven. 2011. “Exploring How Tangible Tools Enable Collaboration in a Multi-Touch Tabletop Game.” Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 6947 LNCS:605–21. Retrieved January 15, 2015 (http://link.springer.com/chapter/10.1007/978-3-642-23771-3_45). Summit, Steve. 1995. “Skills Needed in Programming.” Retrieved January 15, 2015 (http://www.eskimo.com/~scs/cclass/ progintro/sx1.html).
Eindhoven 2015 - Cubi 37
APPENDIX
APPENDIX REFLECTION This project had its ups and downs like any other project. Here I will discuss in more detail what I learned from my final master project, and the opportunities for improvements. In this design project the idea for a product was formed rather quickly by inspiration I found in existing tangible tools. My analytical approach is most often the only approach I take and thereby I miss to take little tests with my end user to find valuable information. My ambition for an idea can lead to a tunnel vision and therefore I need reflection on a daily basis with teammates, which can feed me new ideas so that I keep a fresh perspective. This is something I missed a lot during my final master project, although I am very well capable of working on my own, I perform better in teams. I also see my shortcomings as strong points, as my drive to fulfill my ambition also motivates me and makes me not settle for less. The little tests with children that I have done this project were extremely valuable. Looking back I could have had more information that is valuable for future Tangible tools if I had done more tests but my goal was to fully develop a product myself. Most of the work was done behind the computer in making the software and hardware work. Now it is finally finished and development wherein iterative testing is possible can start. I see this as an opportunity for me to continue this project, that said I only see it possible to continue this project either partime, or with an investor. During the project one of the most difficult questions my coach had for me were what do you want to add with this product, what knowledge will you create with the research you are doing? What are the most important questions to investigate further? There was so much information about tangible user interfaces that I have not even incorporated half of the literature in this report. I am someone who wants to work at the one end analytical and at the other end intuitive. And doing both the things simultaneously did not work. I had to choose for either the creative process where multitasking between
38 CUBI - Final Master Project Industrial Design
soldering, programming, drawing, 3D modeling worked perfectly, or I had to work analytically read write, network, formulate questions, make test plans etc. I have difficulty narrowing down the questions so that they actually can be answered. If possible I want to answer the question if a tangible programming tool would be a good introduction to a visual programming language but in order to create a test case for something like that I simply needed a lot more time. Due to my ambition, perfectionism, and sometimes tunnel vision my planning had to be adjusted a lot of times. I miscalculated the amount of time something would take, simply because I knew I could do it but did not know I would encounter so many problems. Therefore my time management has changed this project over the months, where in the beginning my ambitions gave a lot of stress, later I learned to scale down the ambition and calculate time in for when things go wrong. In the future I would always want to work in a team setting where reflection can occur on a daily basis. After this project I have developed my conceptual, analytical and programming skills to higher level but there is still room for improvement.
APPENDIX
Eindhoven 2015 - Cubi 39
APPENDIX
40 CUBI - Final Master Project Industrial Design