Chapter forthcoming in: Designing Constructionist Futures: The Art, Theory, and Practice of Learning Designs, edited by Nathan Holbert, Matthew Berland, and Yasmin Kafai. Cambridge, Massachusetts: MIT Press.
Abstract:In this essay, we propose a second-order constructionism where learners not only construct knowledge in self-directed ways but also construct the environments that they use to construct the knowledge. Through concrete examples, we show how designers can open up the process of defining learning environments so that learners can play a more active role as designers not just of creative artifacts but of the environments themselves. We conclude with a discussion on the benefits and challenges of such an approach, and with suggestions for future research directions in this area.
Keywords: design; user innovation; learner participation; second-order constructionism;
A core value of constructionism is a commitment to let learners control and direct their learning experiences. Constructionists argue that individuals make connections and construct knowledge in ways that vary significantly from learner to learner. Given these values, it is surprising that the design of the most influential constructionist learning environments—from Logo to Scratch—have relied heavily on top-down design processes based on the experience and insight of individuals or small teams of designers. Most details of constructionist environments are designed by expert designers, nearly always adults, whose role is to create environments with affordances and features that will maximize learners’ ability to follow their interests and to learn in their own ways.
Of course, these designs are frequently quite effective! Designers often spend large amounts of time in the communities they are designing for and make carefully considered decisions about what goes into a toolkit and what stays out (Papert, 1987; Resnick & Silverman, 2005). They frequently follow a growing body of constructionist design principles to ensure, for example, that their learning environments have “high ceilings,” “low floors,” and “wide walls.” But this approach also relies on implicit assumption that there should be clear distinctions between environments and learning activities, as well as between designers and the learners. We believe that some of the most effective constructionist environments are ones that blur the lines between toolkit use and design and—more critically—the role of designer and learners.
How can we support a second-order constructionism where learners not only construct knowledge in a self-directed way but also construct the environments that they use to construct the knowledge? How can designers open up the process of defining learning environments so that users can play a more active role as designers not just of artifacts but of the environments themselves? How can we design environments that learners can both use and change?
In the rest of this essay, we explore these questions while making the case for such a move. Drawing from the broader literature on design, we reflect on how more of the design of constructionist environments can be pushed “down the stack” to learners in less and more extensive ways. To do so, we describe three examples from our experience with Scratch that reflect ways in which the Scratch’s has—implicitly and explicitly—attempted to do so. Finally, we reflect on the promises and challenges of doing so.
Constructionist systems are often described in terms of “toolkits.” We use the term “environment” in this essay to describe both the technological tools that might include a programming language or construction kit as well as the designed features of the social context—like the affordances of an online community or the setting and rules of an after-school program. As constructionist designers have focused more on participation and collaboration, they have described the importance of design of the social context in which learning takes place (Bruckman, 1998; Kafai, 2016). We use the term “environment” to includes these types of contextual features in our scope.
Involving users in the design of their tools has a long tradition in design and computing. These approaches can be placed along a spectrum of end-user involvement. On one end is the idea of the enlightened designer where little involvement is expected from end-users in the design process. At some distance from this point are a variety of human-centered design approaches advocating for closely studying users and eliciting information from them in passive ways like logging and user observation as well as more active techniques like interviews, surveys, and more (Bannon, 2011). Further along this spectrum are participatory design approaches, where end-users are seen not just as informants but as active partners in the design process (Muller & Kuhn, 1993). In participatory design, these partners need not be adults. For example, a significant body of technology design work has shown that young people can be effective partners in designing interactive digital systems for learning, play, and more (Druin, 1999).
Even further along this spectrum are approaches based on “user innovation” which conceives of users as the primary sources of new designs (von Hippel, 2006). In a user innovation framework, a designers’ job is might only involve monitoring users and integrating and disseminating the systems that they create. For example, prefixing words with a “#” to indicate a topic—now called “hashtags”—was a norm created by users on Twitter that was integrated as a feature into by Twitters’ engineers after the practice was widespread. Although frequently hidden and unrecognized, scholars suggest that user innovation is the source of many of the most important and widely used innovations (von Hippel, 2006). For example, although often credited to the language’s original author, the success of the Perl programming language in the late 1990s was driven by the Comprehensive Perl Archive Network (CPAN) which contains over a hundred thousand “modules” published by over ten thousand people. Increasingly, add-on or plugin-based systems are a feature of browsers, games, and many other pieces of software and are sometimes the primary driver of interest in the core system. In some cases, popular modules, add-ons, and plugins are added back into the “core.”
Design approaches based on user innovation shift the locus of design from dedicated specialists to a group of potential designers that includes every user. Despite the increasingly widespread nature of these approaches, most constructionist environments are designed by small teams in a centralized way.
The design of Scratch—built by a small team primarily located at MIT—is not an example of user innovation or participatory design. Scratch was, like most constructionist environments, designed by a small group of thoughtful professional designers. Two of the authors of this piece count themselves as members of that small group over the last decade. That said, our experience as part of the Scratch design team has convinced us that many of Scratch’s most exciting advances stem from more “participatory” turns in the Scratch design processes which has opened up the design of Scratch in sometimes unanticipated ways—frequently with unanticipated results. To illustrate this point, we describe three examples from our experiences.
A first example stems from the way that, like Twitter’s hashtags, Scratch’s design evolved over time by incorporating features that reflected the existing activities of its online community’s members. Before 2013, Scratch had no built-in affordances to allow for persistent or shared data. As a result, users could not easily create survey projects that recorded input from multiple viewers or global persistent high-scores lists in games. Instead, members of the Scratch community systematically repurposed the project comments section of the website to report their game scores, to respond to survey questions posted in the project, and more.
After watching this behavior become widespread, the Scratch Team designed and introduced two interrelated programming features to the programming language in 2013 (Dasgupta, 2013). The first, Cloud Variables, allowed Scratch users to store data persistently in a shared data-store online. This allowed for a number of web application-like projects, such as collaborative digital art canvases and multiplayer games. The second programming feature was the ability to “sense” the username of the community member accessing the project—a new block would return the username of the user viewing the project. Combined with Cloud Variables, this new feature allowed Scratchers to create projects that introduced new social affordances like the ability to respond to surveys. Although designed by the Scratch Team and deployed as part of the centrally controlled platform, the innovation behind Cloud Variables was drawn directly from behaviors that users within the environment had pioneered.
Scratch “mods” and “forks” are two closely related phenomena that describe a more extensive shift of control over Scratch to learners. Mods are a largely unanticipated feature of the fact that the first generation of the Scratch language (in use through 2013) was developed in the Squeak programming language which was itself designed as a programmable constructionist toolkit. Although it was never a documented feature, an Easter egg hidden in the Scratch user-interface allowed any user to open up the Scratch source code and edit it. Scratch “forks” were attempts to build distinct languages based on Scratch by modifying the Scratch codebase.
To the surprise (and sometimes consternation) of Scratch’s designers, a vibrant “modding” culture emerged in Scratch and a small number of forks were published. Developers of mods and forks included young community members of Scratch, as well as adult researchers and educators. Mods and forks introduced new functionality and sometimes added new grammatical constructs to the language. For examples, modders added the ability to scrape content from web-pages from within a Scratch program and several forks added new types of blocks that allowed objects to be programmatically duplicated or “cloned.”
Mods and forks were shared mostly through messages in the Scratch discussion forum. As a design decision, the Scratch team took steps to ensure that projects produced by mods and forks could not be shared on the Scratch community website. This was partly to avoid confusing new members of the community who might be unaware of mods or forks of Scratch, but also for technical reasons. The project interpreter that was used for the website was a separate codebase from the desktop version and was unable to parse non-standard project files produced by the mods and forks. In several cases—like the case of cloning—the Scratch team added functionality first created in mods and forks into the main version of Scratch.
A final example is the Scratch Extension System—an attempt by the Scratch team to allow user innovation within the Scratch community in a controlled way. From early on its in life, Scratch provided a mechanism for a communication channel to be established with an external program running on the same computer as Scratch. Among other capabilities, this mechanism was often used for allowing Scratch projects to interact with external hardware. Building on this mechanism, the Scratch Extension System was introduced in 2015 to allow users to build new functionality into the Scratch language (Dasgupta, Clements, Idlbi, Willis-Ford, & Resnick, 2015). This system was designed to enable anyone to extend the vocabulary of Scratch language through custom programming blocks written in JavaScript. One of the stated goals of the Scratch Extension system was to “enable innovating on the Scratch programming language itself, in addition to innovating through projects.”
By its design, the Scratch Extension system tried to prevent extension authors from changing Scratch’s grammar. Only new commands, event-handlers, and reporter blocks could be introduced through extensions. In this way, an extension could turn on a light bulb, react to a button press, or report temperature from a sensor, but could not define a new type of loop. Through extensions, the Scratch language was opened up to new creative possibilities. For example, an extension allowed speech recognition, so that rather than typing in a response to a prompt, the viewer of a Scratch project could say their responses out loud. Using an extension developed by a Scratch community member, a Scratch project could query Twitter for recent tweets with a given hashtag.
Our three examples from Scratch illustrate how the benefits of allowing learners to play a more active role in shaping and modifying their constructionist learning environment stem from two of the core guiding principles of constructionism. First, environments shaped by learners are better able to connect to learners’ interests. Second, users shaped environments are better able to connect to learners’ knowledge.
For example, users ability to create mods allowed them to create features like the ability to clone objects. As a result, Scratch’s designers did not need to guess that Scratch users would be interested in cloning blocks or be able to use them. They could simply observe that at least some users wanted this enough that had modified Scratch’s code in order to create the feature or install the mod. Similarly, Scratch’s designers knew that Scratch users had the knowledge to use a system like Cloud Variables that provided persistent data stores. Thousands of Scratch users had already painfully reappropriated existing features of the environment by turning the website commenting system into a persistent data store that kept track of high scores or survey responses.
Despite the many benefits of allowing learners to define their own environments, doing so introduces a number of important challenges. First, allowing people to alter their learning environments can introduce interoperability challenges. For example, a group of researchers forked Scratch to create λSnap!, a derivative of Scratch that enabled people to create their own blocks and first-class procedures, lists, and objects (Harvey & Mönig, 2010). Unfortunately, the projects created with λSnap! could not be executed by the Scratch player online nor could be rendered in the original Scratch authoring environment. This lack of interoperability made it such that λSnap! creators could not be full participants of the larger Scratch community.
Second, allowing people to alter the online infrastructure for social interactions can disrupt communication, enable harassment, and curtail participation of specific groups. Scratch published the full source code to its website software early in its life in an effort to allow users to innovate through the creation of alternate Scratch communities. A small group of Scratch community members took advantage of this by creating their own community devoted to sharing hateful Scratch projects aimed to harass members of the original Scratch community. Since this website ran on a server managed independently, there was little that the Scratch team could do about its content and operations.
Finally, allowing users to change their environments might mean undoing many of the benefits that come from centralized control by a thoughtful team of designers. In at least some cases, designers do, in fact, know better than their users. If for no other reason, a small group of designers can ensure consistency and quality that an open and distributed process will not. For example, maintaining design cohesiveness between extensions and the “core” Scratch system proved to be a challenge in the Scratch Extension System. Contrary to established design conventions on Scratch, extensions would sometimes not provide both a “set” and a “change” block for modifying numerical variables or properties, or would include blocks that are complex or that address relatively rare use cases—all problems that would have been avoided in a design created by the Scratch design team.
In their 2005 paper, Mitchel Resnick and Brian Silverman presented ten guiding principles for designing constructionist environments. One of these principles is “Give people what they want—not what they ask for” (Resnick & Silverman, 2005). In this chapter, we have argued that suggest that something more may be gained by enabling people to make what they want. We do so with a healthy appreciation of the challenges of striking a balance between empowering users to define their environment and maintaining a healthy and predictable learning environment.
When the Scratch Extension System was released, Scratch’s designers made a policy decision to make projects with user-created extensions unshareable on the Scratch community website. This decision was made mostly as a means to avoid confusing members of the community, especially newcomers, with unfamiliar blocks. Additionally, the extension mechanism intentionally limited what could be added to the Scratch block palette. Did these decisions restrict the kinds of changes users could make to Scratch too much? Did they not restrict it enough? Striking a balance between the benefits and the challenges remains very much an open research question for constructionist designers.
Bannon, L. (2011). Reimagining HCI: Toward a More Human-centered Perspective. Interactions, 18(4), 50–57. https://doi.org/10.1145/1978822.1978833
Bruckman, A. (1998). Community Support for Constructionist Learning. Computer Supported Cooperative Work (CSCW), 7(1), 47–86. https://doi.org/10.1023/A:1008684120893
Dasgupta, S. (2013). From Surveys to Collaborative Art: Enabling Children to Program with Online Data. In Proceedings of the 12th International Conference on Interaction Design and Children (IDC ’13) (pp. 28–35). New York, NY: ACM. https://doi.org/10.1145/2485760.2485784
Dasgupta, S., Clements, S. M., Idlbi, A. Y., Willis-Ford, C., & Resnick, M. (2015). Extending Scratch: New pathways into programming. In 2015 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) (pp. 165–169). https://doi.org/10.1109/VLHCC.2015.7357212
Druin, A. (1999). Cooperative Inquiry: Developing New Technologies for Children with Children. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 592–599). New York, NY, USA: ACM. https://doi.org/10.1145/302979.303166
Harvey, B., & Mönig, J. (2010). Bringing “no ceiling” to Scratch: Can one language serve kids and computer scientists. In Proc. Constructionism (pp. 1–10).
Hippel, E. von. (2006). Democratizing innovation (1. MIT Press paperback ed). Cambridge, Mass.: MIT Press.
Kafai, Y. B. (2016). From Computational Thinking to Computational Participation in K–12 Education. Commun. ACM, 59(8), 26–27. https://doi.org/10.1145/2955114
Muller, M. J., & Kuhn, S. (1993). Participatory Design. Commun. ACM, 36(6), 24–28. https://doi.org/10.1145/153571.255960
Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. New York, NY, USA: Basic Books, Inc.
Papert, S. (1987). Computer Criticism vs. Technocentric Thinking. Educational Researcher, 16(1), 22–30. https://doi.org/10.3102/0013189X016001022
Resnick, M., & Silverman, B. (2005). Some reflections on designing construction kits for kids. In Proceedings of the 2005 conference on Interaction design and children (pp. 117–122). New York, NY, USA: ACM. https://doi.org/10.1145/1109540.1109556