Keywords

1 Introduction

The apparent fluency of the young people with digital technologies has been observed by their facility in sending text messages, playing online games, browsing the Web. Nevertheless, these so-called “digital natives” are not necessarily fluent in creating digital technology (their own games, animations, etc.); as highlighted by Resnick et al. [20], “It’s as if they can “read” but not “write” (p. 62).

The expression “computational thinking” has gained popularity and interest of academics in the last years, especially after the publication of Wing [24] claiming “Computational thinking is a fundamental skill for everyone, not just for computer scientists” (p. 33). Although the concept is still fuzzy, there is some acknowledgement regarding its meaning as the mental processes that take place when solving ‘problems’ by creating computer programs to solve them. In general, the subject is studied observing and analyzing the way youth are engaged in programming activities during their learning processes.

This subject is definitely not new as Papert [17], already in the sixties, pioneered the Logo language construction and started to study the learning processes of children, engaged in ‘powerful ideas’ mediated by the Logo programming language constructs and the artefacts designed to reach their possibilities. More recently, the work of Resnick and colleagues with the Scratch language, which has roots in Logo’s tradition, has confirmed that programming helps people to learn important problem solving and design strategies such as modularization, iterative design, carrying this knowledge, in some way, to other domains. Moreover, and more important, programming provides opportunities for meta-thinking, as it involves the creation of external representations of someone’s problem-solving process [20].

In this work, we argue that programming is not just a move on internal (in the head) and external (in the program) representations of problem solving. Rather, it has the influence of other artefacts and other people sharing interests and meaning making through different forms of programming together (e.g. by creating narratives, by designing together).

Although not always referring to the early tradition of Logo, the revival of the subject, now with the nomenclature of “computational thinking” owns a lot to its origins, although our perception is that a very technical perspective is being taken on the subject. In our view there are many aspects of knowledge construction, including the informal and formal ones that, besides the technical, should be brought to the situation of programming; among them, the affective aspects of interaction, the social meaning and the creative engagement in a codesign process, to name a few. Thus, by social, we do not mean sharing the product of programming with others in the website of the community; rather, we analyze programming processes and programming environments as spaces for co-construction, i.e. for codesign of a “program”.

In this work, we intend to revisit the early concepts, analyze the recent movements on studying ‘computational thinking’, and seek to understand the computational thinking from a socio-situated and systemic perspective [3, 4], drawing on a recent case study addressing the design of constructionist environments based on low cost tangible technologies.

The paper is organized as follows: Sect. 2 contextualizes and situates the object of study summarizing historical views of programming; Sect. 3 presents and discusses our view of programming as a social construction, the main concepts and principles. The following sections illustrate some ideas with a case study conducted with a low cost tangible programming environment. Finally, the conclusion section summarizes the main findings while suggesting further work on the subject.

2 Background – Computational Thinking

The expression ‘computational thinking’ has gained a revival as a movement to promote the early teaching of programming concepts in the schools, as a new discipline, adding to the math and the other regular ones. This resurgence came after the work of Wing [24], who encountered a perfect timing to relaunch the idea of “a universally applicable attitude and skill set everyone, not just computer scientists, would be eager to learn and use” (p. 33). In the last decade, society in general have been making sense of the digital technology in different manners, and this same technology has provoked profound transformations in the way people live. These transformations encompass all aspects of life: working, learning, having fun, making business, communicating within social groups, and even communicating with things, participating in a world in which computer systems are underlying objects of the physical and social world, mediating our actions in society. Thus, this scenario reinforces the idea of a new literacy more and more demanded. This amplified view of the computational technology in our life brings to question the reach of the ‘computational thinking’ concept. Would computational tool users, procedures followers, digitally literate but not expert in computer science, be included in the target audience of the prospective benefits of computational thinking? or should the concept refer only to mental processes triggered by those creating new code?

Different communities, especially from the Computer Science and from the Education domains of interest seem not always agree on the concept, on the possible benefits of practicing this type of thinking, and on who benefits with the movement. In fact, to understand the expression and situate it in the current social context, a historical perspective on the concept from these different communities is needed. Nevertheless, this does not mean a consensus is necessary, as the different perspectives may add to our understanding of the subject.

2.1 The Origins and Evolution

In the early history of computing, computational thinking was related to the special style of reasoning about problem solving ultimately by ‘coding’ a solution to it. Even the pioneers of Computer Science as Dijkstra [9] and Knuth [14] inquired about the nature of computational thinking, comparatively relating it to its mathematical roots. As compared to mathematical thinking, both argued that the identity of the computing discipline originates from the unique mental processes it promoted.

To characterize the computational mental processes, Dijkstra [9] reflected on the intellectual demands the programmer faces that are typical of him/her. He starts arguing the programmer has to have the ability to express herself/himself in both a natural language and in formal systems. As it comes first, the natural language expression is a necessary ‘tool for thinking’ before any formalization also required, especially when new concepts have to be introduced. For him, the new concepts are not those occurring in the problem statement, but those necessary for the programmer to find, describe and understand his own solution to the problem; and this is an activity the programmer has to do all the time. In his words, “(…) given the problem, the programmer has to develop (and formulate!) the theory necessary to justify his algorithm” (p. 611). Although he recognizes this type of thinking exists in other knowledge domains, he argues that it is heavier in computer science. Besides precision and explicitness, what he thinks is typical of the programming activities is the concerns with ‘size’, for which the hierarchy is considered a key concept. In other words, he is speaking of the level of granularity one has to consider along the problem understanding and the development of its solution. What he considers the particular characteristic of the competent programmer, when compared to thinking in other domains is his/her abilities do navigate back and forth through different semantic levels in the hierarchy, between local and global considerations, microscopic and macroscopic concerns. To this intellectual agility, he named “mental zoom lens” (p. 611). When compared to what a mathematics standard curriculum provides, he suggests the programmer is demanded more on organizing his/her thoughts rather on organizing his/her symbols.

Based on examples of academic works from mathematicians and from computer scientists Knuth [14] studied and summarized two types of thinking patterns computer scientists use that were absent from the mathematicians works he analyzed: one related to the notion of ‘complexity’ and the other related to the notion of the dynamic state Footnote 1 of a process. By ‘complexity’, he meant the economy of operation; i.e. the mathematical works, although constructive, were not paying attention to the cost of construction in terms of the algorithmic efficiency. The second missing thinking pattern is related to the assignment operation, i.e. changing values of quantities. For him, changing states of affairs or seeing glimpses of a computation is typical of algorithms and algorithm thinking. The understanding of data structures for example, which are fundamental in computer science, relies on the ability to reason in terms of processes states and the interaction of processes acting in parallel. He considers dealing fluently with concepts that are inherently non-uniform, like different kind of steps found in an algorithm, a strength of the computer scientist way of thinking.

In the late 80’s, with the formalization of Computer Science as a Discipline by ACM and IEEE, the understanding of computational thinking started to broaden with the definition of 9 (nine) subareas of computing. Besides algorithms, data structures and programming languages, other subjects appeared as core of Computer Science including architecture, numerical and symbolic computation, operating systems, software methodology and engineering, databases and information retrieval, artificial intelligence and robotics, and human-computer communication [8]. For Wing [24], computational thinking includes a group of mental tools that reflects the width of the Computer Science field and we should add it to children’s education, in addition to their reading, writing and arithmetic analytic abilities.

More recently, as computing has been considered the third pillar of science, together with theory and experimentation, a broader description of the discipline is being considered, from the old study of algorithms to the study of (both natural and artificial) information processes [23]. Within this new perspective, along theory and abstraction, “design” skills have been considered central for creating the software systems currently demanded in terms of reliability, usability, security, etc. Thus, it seems we should consider a conceptual movement from programming (coding) to designing (a system).

2.2 Implications in Education

Many people valued the kind of thinking computer science promotes, starting from Knuth [13], who considered it a general-purpose mental tool with potential to aid the students in the understanding of other disciplines such as “chemistry, linguistics, or music” (p. 327). The assumption is that attempting to formalize things in algorithms, leads to much deeper understanding than being told about things or other traditional ways of learning. For Wing [24], among the mental tools experienced with the computational thinking are: using abstraction and decomposition, thinking recursively, heuristic reasoning, planning, choosing appropriate representations and modeling the problem, etc. All those aspects were already present in the works of Papert [17] and his colleagues with the Logo language in the 80’s; the main difference lies in that Papert’s ideas were not restricted to computing per se, rather he targeted a much more profound influence in the education of children.

The concept of “constructionism”, brought with Papert and his colleagues, is a heritage of the Piagetian concept of “constructivism”, supporting the idea that to build a knowledge “in the head” is facilitated when one can build something in the world (a computer program, a drawing, a story, etc.). By constructionism, Papert [16] refers to learning by “making things”, and making them work in the real world, talking about them, and reflecting on our own doing. In his words, “we learn better still if we combine our doing with talking and thinking about what we have done” (p. vi). The constructed things must pass the “test of reality”; if they do not “work” they represent a challenge to understanding and overcoming the obstacles. What distinguish things build with Logo is the contact with “powerful ideas” that enable those things to serve as “transitional objects” for children’s appropriation of the ideas. Logo as a “mathland” – an environment in which children could learn mathematics as naturally as they learn to speak their native language, i.e., without formal instruction, is an instantiation of the constructionist intentions. The “turtle geometry” was what provided the Logo environment with a more accessible way of approaching mathematics than the ways taught in schools.

Concerning technology in education, Papert [16] mentions the two “wings” of it he names “the technology as an informational medium” and “the technology as a constructional medium”, stressing there is an imbalance on them, culture being dominated by the informational one, although both are important. Part of learning is related to getting information (from a book, from listening the teacher, for example), and part is related to building things valuable for the learners. For Papert, this imbalance may be the result of lacking suitable technology-based environments as constructional medium.

Besides being a theory of learning, the constructionism and Logo’s philosophy represent a strategy of education, a way of thinking in computers and education, and a guide to the design of learning environments. The agency of the learner in the learning process and in the environment may be what best characterizes a constructionist approach to children’s involvement with programming. Nevertheless, besides the informational and the constructional dimensions involved in those learning environments, we argue that a communicational medium is lacking if we want to consider widening the types of thinking to encompass also design; this medium would be necessary for a social shared construction in the learning environment.

3 Programming Systems and Socially Aware Environments

For Tedre and Denning [23], “Design is the bridge between the technical and the theoretical realms of computing and the needs and problems of communities and customers” (p. 124). A project for the inclusion of computing technology in a formal learning space (e.g. a school), in our view, must be built with the parties that involve that space as an organization, in its informal, formal, and technical aspects. As in a constructionist environment, they bring their own knowledge, experience and inventiveness to the situations at hand in the Project; at the same time, their participation in the process allow them the construction of meaning for the technological artefact, as well as more awareness of their own learning process.

The challenges of a project involving digital technology, education and society demand a systemic, socio-situated vision [3] and involve:

  • At the societal level, to reduce disproportionalities in access to and use of knowledge;

  • At the formal level, educate for/with the use of technology and new media; essential aspect to empower citizens with the skills necessary to guarantee the universal right to information and freedom of expression;

  • At the technical level, create inclusive environments and systems that can support the constitution of a digital culture where the parties are also knowledge producers.

Implicit in our model is the recognition that communication among stakeholders and interested parties is a culturally defined social phenomenon and the artefacts constructed to mediate such communication must ensure their creative and collaborative use in order to lead to proposals for technology use that make sense to those involved.

Our framework draws on the “semiotic onion”, adapted from Stamper et al. [21], as the conceptual basis of our understanding of designing information systems. It illustrates the structure of informal, formal and technical layers of meanings in the conceptual model we use for the socio-situated view of a problem/project understanding and the “solution” to be designed (Fig. 1).

Fig. 1.
figure 1

The ‘semiotic onion’ model for designing a project [3, 4]

Full size image

In our understanding, solving a problem (e.g. through the computer, but not restricted to it) involves a systemic thinking, situating the “program” in the nucleus of the “semiotic onion” in which informal, formal and technical levels of meaning of the social group coexist. At the outer (informal) levels, meanings and intentions are established, beliefs are formed and commitments are established and changed. At formal levels, forms and rules replace meanings and intentions of the outermost levels of the onion. At the technical levels (onion core), technical solutions (coding) are generated as consequence of meanings in the previous levels. Thus, designing a solution to the problem involves the articulation of the three layers of meanings related to the problem/project, by the involved parties.

In the proposed framework, understanding the problem, analyzing and proposing solutions, evaluating results of actions throughout the project are built by the action of the participants in workshop dynamics. The foundation of the whole process is the workshops, named Semioparticipatory [1, 3, 4] in reference to their bases, that articulate meanings of the (social) world towards the (technical) system and vice versa. Several artefacts are used in the workshops, such as a diagram of interested parties (DIP), an evaluation frame (EF) and a semiotic ladder (SL); other artefacts are customized to the aims of each workshop and its audience. The DIP supports the participants in raising awareness regarding the (other) parties direct or indirectly involved in the problem, the reach and impact of the solutions in not only technical terms, but social as well. The EF enables anticipation of problems the interested parties would face with the prospective technology, to propose solutions. The SL allows organizing and sharing the demands of the Project in six different layers of information, going from the physical world, to the social world, passing through the empirics, syntactic, semantic and pragmatic steps [22]. Figure 3 in the next section illustrates some artefacts and workshops conducted with the interested parties in the context of a tangible programming environment Project.

The proposed socio-situated framework represents computing technology as a social invention and, in a Project, promotes the sharing of responsibility in its reconceptualization, giving voice to the stakeholders in the design and development of the Project with its communicational mechanisms. The situations fostered in the Semioparticipatory workshops open space for this expressive manifestation of the parties and their understanding requires immersion of the facilitators in scenarios for which traditional methods of design do not fit.

Thus, instead of bridging the gap between the technical and the theoretical computing issues, in the perspective we bring with this framework, designing a computing system should be a continuous movement from social to the technical issues, and back to the social; the theoretical computing issues are underlying this movement.

4 Designing TaPrEC: A Low Cost Tangible Programming Environment for Children

Even recognizing the potential benefits of developing computational thinking, literature has shown that children have difficulties with the traditional form of programming, not only in learning the syntax of rigid symbols, but also in the use of complex programming environments [7]. There are authors [11] who affirm that programming languages based on TUIs (Tangible User Interfaces) [12] have the potential to facilitate the learning of complicated syntaxes, to promote collaboration, and to facilitate teachers to maintain a positive learning environment.

Nevertheless, tangible technology is considered delicate, expensive and non-standard [10]. This can be a problem in educational contexts where cost is a deciding factor when choosing a particular technology. Another important factor to consider is the process of including tangible programming environments already existing in an educational context different from which it was thought. Forcing a technology into a new educational context can be a slow and complicated process.

Considering the above, we have designed, created and evaluated the Tangible Programming Environment for Children (TaPrEC), involving the main stakeholders (researchers, teachers and students) in the design process to ensure that the solution created make sense to them. In this process, we used the Semioparticipatory Design Model [1, 3, 4], inspired by Organizational Semiotics, which articulates at the same time the development of interactive systems and social practices with stakeholders. In this model, the user concept does not fit and is replaced by “interested parties”, as a way to respect values, interests and competences of those involved in the product and/or design process. This reconceptualization of roles implies recognizing in users the competence to design and enabling their creative and responsible involvement in design solutions.

TaPrEC allows children to create computer programs by organizing tangible objects, applying three basic programming concepts: Sequences, Repetitions, and Procedures [6]. The architecture of the TaPrEC consists of a Raspberry Pi [19], the RFID technology incorporated in the Programming Blocks and a Processing Software developed in the programming language Scratch [20]. We aimed at proposing an environment to enable children to learn basic programming concepts, which is a low-cost alternative to teaching programming in schools and potentially allowing a smoother transition to virtual learning environments and the world of computer programming.

4.1 Design Rationale

The vision of the TaPrEC environment is to promote the development of computational thinking in the context of elementary school students through the programming l based on tangible interfaces. Among the key requirements of the environment were: (i) users should be able to build ‘physical’ computer programs by organizing tangible objects and applying basic programming concepts such as Sequence, Repetition, and Procedures; (ii) the environment should require a minimum cost investment; (iii) the environment should have tangible objects using a simple, although robust technology, to allow easy maintenance, and personalization; (iv) the software used for data processing and the creation of learning scenarios should be as simple as possible to facilitate the customization and creation of new learning scenarios by the teachers themselves; and (v) in the design process, key stakeholders should be involved to ensure that the solution created makes sense to them.

One of the main motivations of our project is to use technology accessible to socioeconomically disadvantaged populations without making a huge investment, while maintaining the quality of the interaction. For this purpose, we chose to use Raspberry Pi 2 B Model, a low-cost single-board computer. The other technology used in TaPrEC is a Radio Frequency Identification (RFID). The operation of RFID systems is simple: the RFID tag, which contains the identification data, generates a radiofrequency signal with this data. This signal is detected by an RFID reader, responsible for reading the information and sending it in digital format for a specific application.

The second component of the environment is the Programming Blocks, which is a set of colored pieces of puzzle-like wooden blocks containing an RFID tag on one side and a graphical symbol on the other as label for the block. We embossed the symbols to enable a visually impaired person, for example, to build tangible programs. The colors of the programming blocks are inspired by the Scratch language to allow a smooth transition to its programming environment later.

The third component of the TaPrEC environment is the Processing Software, developed in the Scratch 1.4 programming language. The software stores the identifiers of the RFID tags of the Programming Blocks. Codes that represent the same functionality are grouped into a list. When the program receives a sequence of identifiers, it: (i) checks if the identifier matches any of the action lists; (ii) execute the Scratch code associated with this action; finally (iii) shows the results in the Scratch environment. Figure 2 illustrates the TaPrEC environment constructed, its components and the architecture of the system showing how its three components interact with one another.

Fig. 2.
figure 2

TaPrEC physical environment (left) and system architecture (right)

Full size image

The control blocks indicate the start and end of the program. The tangible program information is entered into the TaPrEC environment through the RFID reader. The environment has a limited number of basic commands. To construct a program in the TaPrEC environment it is necessary to organize the Programming Blocks in a specific sequence: first the start block, then the action blocks and finally the end block.

4.2 The TaPrEC Usage Experimentation

Context and participants

The TaPrEC project was developed with a partnership of the Division of Children’s Complementary Education, which is an educational space inside the University of Campinas, in Brazil, State of São Paulo aiming at supplementary education for the children of the university employees. In that educational physical space, we carried out the activities in the atelier room. The activities were formally scheduled by the coordinator of that Division in the set of weekly activities of the involved teachers and students. The Research Ethics Committee (CEP) of the university approved the project.

The practice of using the TaPrEC environment we are going to illustrate here occurred along the year of 2015. In the next subsection, we present some results of the workshops, conducted with both the teachers, and children separately within the TaPrEC environment. We worked with sixteen children between 7 and 10 years old, and with thirty eight teachers between 31 to 54 years old.

Method

Eleven (11) workshops were conducted along the semester, with teachers of the educational unit, and 10 with children and their responsible teacher. During this process, the system was being introduced and its design being yet refined. We conducted two types of workshops: Experimental Workshops (EW) and Semioparticipatory Workshops (SpW). We filmed all workshops, after the written consent of all participants or their respective representatives in the case of children. The videos allowed us to observe the behavior of the system environment, demands for improvements and for new functionalities along the process, and the participants’ actions.

In addition to filming, at the end of each workshop all participants (children and teachers) filled the SAM (Self-Assessment Manikin) instrument [5]. SAM is a nonverbal instrument of self-assessment of emotions, specifically the level of pleasure, arousal and dominance, associated with the affective reaction of a person to a stimulus, in this case, the TaPrEC environment they were experimenting.

In two Workshops with the teachers, we worked with the artifacts of the Semioparticipatory Design Model [1, 3] with the objective of articulating solutions to the anticipated problems encountered during the use of the TaPrEC environment. We used the Stakeholder Diagram [15] for participants to identify those directly or indirectly involved with the project. The teachers talked and identified the different stakeholders and began to locate them in the layers of the diagram. With the Evaluation Framework [2], participants anticipated problems and issues of each stakeholder regarding the use of the environment, its use as a support tool in the different activities of the school and possible solutions. With the Semiotic Ladder [21, 22] participants were able to understand the different implications of the environment from the physical world to the social world.

During the Experimental Workshops, we worked with the teachers and the children separately. In each workshop, the participants formed teams to solve simple exercises of displacement of a character in a scenario, applying the programming concepts implemented in the TaPrEC (Sequences, Repetitions and Procedures) environment.

The dynamics of the workshops involved: first, a quick introduction on the concept of programming focus of the particular workshop, followed by the explanation on the operation of the tangible blocks associated with that concept. In the sequence, each team worked the proposed problems by planning a solution (in a paper), setting up the solution organizing the tangible objects, and finally inserting the tangible program into the TaPrEC environment using the RFID reader. The processing software was in charge of executing the tangible program and showing the results. The last step in the workshops involved the affective evaluation of their experience in the workshop, where teachers and children were invited to complete SAM. In Fig. 3 (top) we illustrate a SpW with teachers, and the three moments of the Experimental Workshop with children are illustrated in Fig. 3 (bottom).

Fig. 3.
figure 3

Semioparticipatory Workshops with teachers and artefacts being filled (top) and the three stages of the Experimental Workshops (bottom)

Full size image

Results

From the Semioparticipatory Workshops

With the collaborative construction of the Stakeholders diagram (Fig. 3, top, the artefact hanging on the left) we sought to clarify the real scope of the project and its importance not only to those directly involved in its operation, but also to the entire community. The teachers raised the parts that direct or indirectly influence or undergo the influence of the project. Some stakeholders raised by the teachers were: trainees placed in the Contribution layer; the school management group placed in the Source layer; the pedagogical games on DVD placed in the Market layer; and non-governmental organizations placed at the community level.

Once teachers identified the parties involved in the project, teachers began to fill out the Evaluation Framework (Fig. 3, top, the artefact in the middle). The group discussed specific issues/problems of each of the Stakeholders for the use of TaPrEC and raised ideas or solutions envisaged. For example, in the Operation layer they raised the following question/problem: “In what type of activities would the environment be better utilized?” The answer/solution raised was: “the environment could be used to help math, literacy, socialization and motor development.” The results of this discussion were essential to clarify the demands on each of those involved parties.

With the Semiotic Ladder (Fig. 3, top, artefact on the right), the different abstraction levels of the TaPrEC project were clarified, from the physical level where each of the devices used in the environment were identified and explained, to the social world where the development of computational thinking promoted by the environment was highlighted.

From the Experimental Workshops

During the Introduction phase of the Experimental Workshops we explained the syntax of programming blocks through a simple tangible program that illustrated the concept to be worked on in that Workshop. In the Execution phase, we visited each work team answering the doubts of the participants. The children collaborated with each other in solving the exercises, suggesting which programming blocks to use, as well as their order and quantity. The results of the work groups show that our dynamics allowed participants to learn the logic to construct a tangible program in the TaPrEC environment (beginning, sequence of actions and end) and programming concepts (Sequences, Repetitions and Procedures). In general, all teams were able to make a plan for their tangible solution and execute it with the blocks in the environment. The researchers helped the work teams by making suggestions or observations that helped them to find the mistakes of the tangible solution and thus manage to solve the exercise. We observed that the main difficulty some participants had in one of the Workshops was to understand that during the definition of a procedure the tangible program does not perform any action; only when the procedure is invoked by its name, it executes the actions previously defined. Despite this difficulty, other groups demonstrated that they understood the concept and operation of this programming concept. Regarding the symbols used in the tangible blocks, children sometimes confused the “End Repeat” symbol with the “End” from the control block. This is probably because both blocks used a similar (circular) symbol.

The solutions (algorithms) created by the groups of participants should result in a specific action (create a geometric figure, walk the right path in a labyrinth, etc.); we observed how the participants faced error correction situations until reaching the established goal. Some teams were able to get the correct solution on the first try (after planning), others faced with not expected responses, began the debugging process. First, they checked whether the paper solution matched the tangible solution. Sometimes it happened that they forgot to put some programming block or they had put one block in place of another. If both solutions coincided, they began to analyze the tangible program by sequentially comparing the tangible program blocks with the result shown on the monitor to find out the program error. During that debugging process the children talked with each other in the group raising suggestions to correct the tangible program, some suggested changing one block for another, others wanted to reduce or add the amount of a particular block. When the children took a long time trying to find the mistake, they became anxious and asked for help, but when they were able to solve the problem, they felt pride and joy.

The teachers were exposed to the same type of problems as the children and did not present difficulties in solving them. The objective of working separately with teachers was to enable them to operate the environment so that in the near future they could customize it and create their problem situations to work on different themes using programming concepts with children. We received many suggestions from teachers along the Workshops who helped us to improve the environment and the organization of the Workshops; one example of suggestion was “to improve the designs of the programming blocks labels to facilitate the interpretation”.

From Affective Evaluation

The results of the Self-Assessment of Emotions were almost all positive with both children and teachers. Only the workshop addressing Repetition showed a neutral result regarding affective states with younger children (7 years), still in the process of literacy (with difficulty for the paper planning stage, for example). The Workshop addressing Procedures was conducted with older children (8 and 9 years old), which showed an excellent result (100% pointing out positive feelings).

5 Discussion

Incorporating the use of a new technological tool in the classroom is not limited to teaching how to use it simply; part of the process is to work out challenges related to technical issues (such as how to handle and maintain technology) as well as pragmatic issues (what to do with technology in activities related to school content). Similarly, including a programming environment in an educational context should not be disconnected of meaning the involved people (children, teachers, managers, parents) make of it. That is why our environment is not only focused on the technology used to create a tangible programming environment, but also on supporting the stakeholders, those people affected direct or indirectly by the Project. The Semioparticipatory Workshops conducted in the scope of this work resulted in several outcomes: (i) for the teachers to understand and reimagine how the inclusion of the TaPrEC environment in the daily life of the school could support different activities and skills developed with the children; (ii) for all the involved people to understand the influence of other stakeholders (e.g. trainees, director, coordinator) in the process; (iii) and for anticipating problems different parties could have regarding the technological environment and its use, and propose solutions.

When we planned the Semioparticipatory Workshops, we decided to carry them out after the Experimental Workshops, so that the teachers had a broader view of the functioning of the TaPrEC environment with the children and could better understand possible problems in the process of incorporating the environment into activities with their students. Teachers imagined the use of the TaPrEC environment as a support in the teaching of mathematics, space orientation, logic and literacy, not the programming per se. Nevertheless, they emphasized the opportunity for children to create their own programs and to know the computer from another point of view, not exclusively as users of applications.

In general, the preliminary results regarding the TaPrEC design as well as its use with the children were very encouraging. Nevertheless, it is worth analyzing Tedre and Denning [23] list of seven risks the new enthusiasm for computational thinking revival could bring and we should avoid. They are commented as follows, as an opportunity to reflect on our own work:

Lack of Ambition.

The first risk they call our attention for is the scope of understanding for ‘programming’ in a world very much different from that of the 80’s. The digital systems have become an integral part of everyday life, underlying our processes of communication, making business, working, learning, living in society. Thus, in this context, our conceptions of literacy must be revisited to include other forms of digital composition, besides coding. The analytical abstract world, as used to be seen in computing, should give place to a view that includes the (social) complexities of the (real) world. A socio-situated approach to systems design, illustrated by the design of TaPrEC - the tangible programming learning environment, involving the interested parties was carried out as an effort towards a new way of looking at programming practices and programming environments design for educational contexts.

Dogmatism.

This risk is related to the claiming of computational thinking to be the “best” way of thinking in problem solving, over other forms of thinking, e.g. design thinking, science thinking, critical thinking, ethical thinking, etc. Instead, we should have Papert’s spirit of epistemological pluralism to the subject, being open to alternative approaches to problem solving thinking. In our proposal, a holistic and pluralistic view of ‘computational thinking’ is envisaged with the socially aware framework to the design of (software) systems, in which the interested parties are directly involved in socio-situated contexts of design. Their voices are brought together with the designers and other interested parties voices to the process of designing the environment and to the ways of using it.

Knowing versus Doing.

The third risk, according to Tedre and Denning, concerns the assessment of the students for their competencies at designing computations. Those authors observe there is a difference on the concept of skill and of knowledge of facts or information, and the relationship between these knowledge progressions, as measured by formal frameworks available for K-12 education (in the USA), and skill or competencies acquisition is unclear. In our approach, the children are programming together, doing it in groups, in a participatory way; mutual learning is shown by the results the groups accomplish in interacting and communicating to solve a problem. They are learning not only by making things work in the programming environment, as in Papert’s Logo projects, but also by communicating with their peers along the process of constructing the solution together.

Exaggerated Claims.

This risk regards repeating the same mistakes of the past by not considering the historical view and the predecessors’ studies in this subject. It regards also the still unsubstantiated claims that computational thinking confers problem-solving skills transferable to non-computational knowledge domains. This debate continues and the answers, in our view, are not reachable looking only into the cognitive processes (in the head) of those engaged with the types of mental processes specific of computer scientists, nor in the computation represented in the coding (in the program). Rather, it may be hidden as well in the way people affectively relates to the subject and work together to communicate and make sense of the solution in their situated contexts (in the world, in the life).

Narrow Views of Computing.

This risk is concerned with considering “coding” as a central issue of the computational thinking and of the computer science. Tedre and Denning argue that reducing computing to programming is a myth from the 70’s, never embraced by the pioneers of computer science; moreover, coding skills are less and less relevant to the design challenges and design tools of contemporary computing. A deep understanding of the discipline in its breadth in terms of computational thinking is needed to avoid that risk. The semiotic framework we draw upon enables to see programming as designing in different layers of sign system, bringing issues of the social and informal nature (culture, commitments) to the formal and technical levels of a computer system.

Overemphasis on Formulation.

This risk regards the use of the word “formulation” in the descriptions of computing and the computational thinking. Tedre and Denning claim that while it can be understood as “designing computation”, it also can be interpreted as “expressing commands calling a computation” and this second meaning does not necessarily regards computational thinking as people can issue commands (or push buttons) without engaging in computational thinking. They propose instead of “formulation”, “design”. While we agree with their proposal, we take a wider meaning for design, not restricting it to design of computation, but understanding design as a process that encompasses the informal, the formal and the technical levels of information if we are to construct computer-based applications that enrich human life in the world.

Losing Sight of Computational Models.

The seventh risk regards the relationship computational thinking has with the behavior of (practical or theoretical) machines; one should not lose that insight for not risking an exaggerated claim about the computational thinking. In our work, TaPrEC offers a tangible (accessible, practical) but also subtle way of presenting the relationship between certain concepts and controlling a machine to have things (problems) done. Besides being a tangible programming environment designed for children to experience programming in their different and uncomplete levels of apprehension, it is also an ‘object to think with’ for us in designing programming learning environments. As so, TaPrEC is situated in the technical layer of the semiotic framework, embedding and supporting formal and informal issues considerations (e.g. cost).

6 Conclusion

In the last decade, the digital technology has provoked profound transformations in the way people live in society, certainly requiring attention to a new type of demanded literacy. Programming has been argued as a new discipline to support such technological fluency, due to the types of mental processes it triggers. The transformations we have experimented with the digital technology encompass all aspects of life as computer systems are underlying objects of the physical and social world, mediating our actions in society. This amplified view of the computational technology in our life brings to question the reach of the ‘computational thinking’ concept as it has been presented in literature. In this paper, we shed light on this subject by revisiting early studies on computing and computational thinking, as well as recent works discussing the matter. We added to the old debate in computer science, of those who question the ‘coding’ versus the ‘systems’ views for programming, by proposing an integration vision which recognizes a social nature in programming.

The approach presented in this work draws on a semiotic framework to see programming as designing in different layers of signs system, bringing issues of the social and informal nature (culture, commitments) to the formal and technical levels of a computer system. We illustrated the approach with the design of TaPrEC, a low cost tangible learning environment created to introduce programming ideas to children. The low cost requirement addresses the challenges of disadvantaged social contexts, and problem solving through programming in that environment is practiced as group work. The teachers and other interested parties were also involved along the design and use of the environment, having voice in it and sharing their concerns. Other works have been developed within the same conceptual framework, addressing alternative ways of getting in touch with programming ideas, as for example by constructing narratives [24], but are left out of the scope of this paper. Results so far encourages the openness search for fluency with digital information technology by reflecting on the social nature of computing.