/witch doctor mask construction

/24 thesis graphics

/draft code vocabulary

A first draft of a code dictionary / vocabulary / thesaurus. This is a first visual draft of a timer sample in Arduino, separated between code, control flow and data flow. The hypothesis is that a dictionary of patterns would help interaction designers to assemble their programs. 

/Code Companion Mk.I

An intermediate result of my research. The Code Companion (CC) is a paper tool to help with programming and bridge the gap between idea and code. The Code Companion is essentially a white sheet of A3 with separate areas for different code elements, also see below. The steps of the code companion are based upon a model distilled from designers, as a previous part of my research. 

Step 1 - Inputs & Outputs:
The first step is to determine the input(s) and output(s) of the code. Which value(s) and/or behavior(s) do you begin with? Which ones are the result of your code? Think about numerical values, actions required for the sensor to registrate and actuator actions as possible inputs and outputs.

For example: A touch sensitive lamp might have touch intensity as an input and brightness of the lamp as an output.

Step 2 - Tools:
The second step is to determine the tools required to get from input to output. Transformers are tools that alter, add, subtract or generally change data & memory items. Conditions are tools that determine when actions or tools occur. Finally, data and memory are storage tools that contain information that might be altered in one way or another through transformers.  

Example:  “touch intensity ”and “brightness” might both be data tools. “Compare-and-change” might be a transformer that turns touch intensity into brightness and finally “after 10 seconds of touch” might be a condition tool that determines when something happens.

Step 3 - Path:
After determining begin and end conditions, and imagining the tools required, use them to sketch out the path between start and end. This path is effectively what will be formalized in the computer by programming. The path is what will help you define how the idea should be translated into computer readable code. 

During the sketching process, or during programming,  tools could be missing or not defined yet, one can always evaluate and revise the tool list to keep the model updated. 

Example: An example can be seen below and in large here.

The Code Companion is a tool that forces novice programmers to think in the ways of the machine, before immediately beginning to program. The CC should be used before programming, but after the idea has been created. Even without programming knowledge, this structured approach forces the designer to think about his idea in a way computers should be able to interpret.

The Mk.I version of the Code Companion is only a preliminary version which has been used to test at students in programming workshops. Another iteration will be coming soon. The PDF of the first Code Companion can be downloaded here, and the instruction sheet can be downloaded here. 

/Alan Turing graphic

A graphic for one of the subchapters of my thesis.

/timeline of computing infographic

An infographic that shows the most influential discoveries and developments throughout the past 3 centuries of computer science. The events have been selected based on the relevance for my thesis, and are predominantly of influence to programming for designers. 

The full version can be seen here. 

/introduction to interactive prototyping

The past two weeks, I have been spending time giving two workshops related to Arduino, introduction to interactive prototyping and learning programming for designers. Implementing parts of my research together with learning new things how designers acquire programming skills, and which elements of programming are difficult for them. 

First at the Artesis University College of Antwerp, together with PhD researcher Dries de Roeck.  Theme of the workshop was design for kids combined with “the internet of things.” Students were given one of five design contexts, related to classic toys for children. During the week, they had to got through making an interactive network of things, similar to “the internet of things”.

Pictures, material and results of the Antwerp workshop can be found at the workshop blog, more general information about the workshop week can be found here. The blog includes pictures, code examples, presentations and parts of the students’ process. 

The second week, together with Dr. Walter Aprile we gave a workshop at the Glasgow School of Art. In this workshop, students of the department of product design were asked to design an interactive drinking game; a game that combines chance with a skill element, which gets gradually more difficult as the players get more intoxicated. 

Pictures & materials of the workshop in Glasgow can be found at the blog. 

The interesting results of these workshops were related to connecting with designers that have no experience in programming. We have seen students thinking there are ghosts in the machine, inexplainable errors and other intrinsic thought processes unique to designers that are learning programming. For my research, more detailed results will follow in the future. 

/modkit: in-browser programming environment

“Modkit is an is an in-browser graphical programming environment for microcontrollers. Modkit allows you to program Arduino and Compatible hardware using simple graphical blocks and/or traditional text code. Modkit’s graphical blocks are heavily inspired by the Scratch programming environment developed by the Lifelong Kindergarten Group at the MIT Media Lab. Modkit runs in your web browser and requires our Desktop Widget to communicate with your development board. You can use Modkit for free or join our Alpha Club to support Modkit and enjoy additional features before their release to the general public.”

As there are many visual programming environments for the Arduino, Modkit specializes in online environment. Which is by my knowing, the only one. The nice thing is that it combines digital hardware similar to Fritzing, visually assembling code and a textual code view to see what is going on. Modkit has a component interface which allows dragging and dropping of components, connecting pins and so on. It comes with a variety of known boards, as well as its own board; the MotoProto Shield.

Modkit is inspired by MIT’s Scratch, which is an educational programming environment for children. By assembling logic together, Scratch can be used to create small interactive programs and animations. Also, both Modkit and Scratch have their vocabulary completely included. So all the building blocks you can use, are already there in the environment. 

Modkit excels in one particular thing, which is the reduction of installing drivers, programs, et cetera to make it work. Programming microcontrollers never has been so easy to get into. Fire up the browser and plug in your USB. It successfully removes the barrier of doing stuff that is necessary, but does not make any sense for the novice programmer (drivers, using terminal to locate libraries, compiling, et cetera). 

To conclude I see two drawbacks of Modkit. The first drawback of the free version is gimped. You cannot use variables in the free version. This renders it completely useless and one would have to buy the Alpha membership of 50$/year or $199 for a lifetime subscription to actually use it.

The second drawback is more of a fundamental nature. Peter Deutsch once stated:

You can’t have more than 50 visual primitives on the screen at the same time.

If you are programming visually, there is a limit to the complexity. Not in terms of what you can achieve, but especially in terms of debugging and solving logic errors in particular. Finding the error as well as understanding how the code acts through the visual layers can be particularly frustrating and difficult for more complex code that goes beyond the simple act of turning LEDs on and off. Also see my Scratch version of the Space Invaders for an example of this visual spaghetti code.

/world of programming (update)

Renowned designer Dieter Rams decided to learn programming, to create his own prototypes and become a better designer. Determined to begin his journey into learning the madness of programming in C, Dieter turned to his mentor, Alan Turing for help. 

Dieter sighed as he puts his book aside. “Mr. Turing. I am sorry, but this is getting me nowhere.” He stared at the green and black terminal again. 
Alan Turing, who recently celebrated his 70th birthday turned towards Dieter. “Back in my day, we were talking directly to the machines.” Mr. Turing shook his head. “We didn’t have all this newfangled technology to help us.” 
“These things just don’t make any sense to me. I’m afraid this computer science business is just not for me,” Dieter continued. 
“Nonsense.” Mr. Turing retorted. “It should be accessible for everyone now, high-level programming languages such as that one make sure of this.”
Frustrated, Dieter grasped the book again. The cover depicts a blue, bold C on a white canvas. “How am I supposed to learn, if none of these explanations make any sense?” He sighed again, flipping through the thick book. “Nicht brauchbar oder verständlich.” Dieter muttered to himself, shaking his head. 
Mr. Turing stared at the terminal stationed on Dieter’s desk, the blinking underscore patiently waiting for new input. “So, what is it that is troubling you, Dieter?”
“The whole picture!” Dieter cried out. “I don’t have a clue about compilers, what they are, what they do and where to compile something! And then there are data types, determinism, state, imperative, procedure…”

“Oh dear.” Mr. Turing sighed. “I have an idea. Let’s forget all this for a minute and go back to the start.” As he browsed through Dieter’s bookshelf and stopped at a particular title: Chemie: die Elemente des Periodensystems. “This one will do.” 
“What does chemistry have to do with programming?” Dieter asked. “Isn’t learning one intangible discipline enough?” 
“You will see for yourself.” Mr. Turing looked through the pages. “Ah yes, here.” He stopped at the periodic table of elements and placed the book in front of Dieter. “Imagine that the world of programming consists of several layers.”
Unsure of where Mr. Turing would go with this, Dieter looked at the table in the book.
“Matter, molecules and the elements.” Mr. Turing started. “If we ignore quarks and other sub-atomic particles, this is all that exists in the programming world.”
Intrigued, Dieter nodded as he tried to keep his train of thoughts on track as Mr. Turing continues to explain his analogy.
“At the smallest possible scale, computer science has elements, also known as the atoms. These atoms are the mathematical concepts and principles that define this world.”
As Mr. Turing flipped the page, Dieter studied at the following page. An image of a molecule was present. White rods connecting black and red atoms together into structures. 
“On a higher level, specific combinations of elements form molecules, which resemble world-views of our programming world. More commonly, these are called paradigms. The molecules, or paradigms shape the way the matter looks and works, and how we perceive and interact with this matter.” 
Dieter looked slightly puzzled from the overload of information. “So, what exactly are these atoms? Are they like building blocks, as in chemistry?”
“Ah, excellent question Dieter! Concepts of computer science such as record, procedure, state, and even my theory about Turing machines is part of it.” Mr. Turing said, somewhat proudly.  
“And the molecules?”
“The paradigms, or molecules as we call them in this analogy, are views on our programming world such as functional, object-oriented or imperative programming.”
“So if I understand what you are saying, Mr. Turing is that the terminology can be subdivided amongst the three levels of concepts, paradigms, and languages?” Dieter asked, excitingly. 

“Not really, we are not there yet.” Mr. Turing replied.
Somewhat disappointed from the anti-climax, Dieter frowned as he clearly hoped that by now, he would have understood the matter. 
“We still miss some things in our analogy. Imagine that the matter forms both an Earth and the atmosphere. Where the Earth resembles the programming languages, the atmosphere everything that surrounds the languages.” Mr. Turing said.
“Surrounds the languages? You mean as in references?” Dieter asked. 
“Exactly, but not only the references but also things such as books, communities, education and educators. You, as a programmer, stands on the surface of this earth, interacting with both the language as well as it’s surroundings from a specific  point of view; a programming paradigm.”
“Finally.” Dieter concluded. “And this world view determines how we see and interact at the language level and it’s surroundings.  Now I understand!“

/wondrous world of programming

This is a draft graphic of how I am perceiving the world of programming at the moment. It is not finished, however it already gives the rough structure of how I am envisioning this world from my designer’s point of view. The metaphor of elements, molecules and matter tries to give shape to the vague definition of concepts, paradigms and languages.  

 

The primary building block in the world of programming are the concepts of computer science (turing completeness, state, (non)determinism, record, lexical closure, et cetera). With these building blocks, or elements one can ‘assemble’ programming paradigms such as functional, imperative, object-oriented, et cetera). One or more molecules or paradigms can form matter, the programming language and everything that is around the language (documentation, IDE, reference, social communities, et cetera). Finally, at the core of the language, there are both the syntax and semantics.