Programmable Learning Technologies and the PLT Framework

Overview

This project involves the development of a framework for classifying programmable learning technologies and critically thinking about how their features and resources affect learning and curriculum design. To view more about my studies involving the PLT Framework, see Teacher Preparation in STEM+C Pedagogy.

Hold on, what is a “programmable learning technology?”

Programmable learning technology, or PLT, is my term for an interactive, educational technology tool that is used for learning computing concepts and programming. I use this broad definition in all of my work to be more inclusive of technologies that I might not know exist yet or that have yet to be used for educational purposes. This category includes tools such as:

• online code-learning platforms (ex: Replit and Code HS)
• maker programs (ex: Scratch and danceON)
• tangible devices (ex: Arduino and Raspberry Pi)

What is so special about PLTs?

Aside from being a great and interactive way to teach computing, many of these tools have been the subject of computing education research over the past two decades and share a purpose in helping students be successful in programming. However, within their differences lie unique properties subject to the features of the PLTs and the resources meant to support them. By understanding how these properties directly and indirectly shape learners’ experiences, we can compare PLTs of any kind, identify their benefits and challenges to learning, and uncover nuanced connections between them.

So, if PLTs are so great, then what’s the problem?

I’m glad you asked! Advancements in AI, robotics, and new avenues for online learning have led to increased production of PLTs. These innovations, while promising, have led educators to grapple with where and how to integrate computing and AI into their curricula, and whether doing so serves the best interests of their students. My work explains learning phenomena through critically analyzing the interactions learners have with PLTs, and more specifically, the features and resources that they comprise.

You’ve been saying “features” and “resources” a lot…

Yeah, I know, and that will make sense in a little bit. Just know that this project is all about classifying the unclassified, so I try to use terms that are specific enough to capture the main point of what I’m saying, but also not too restrictive.

Before you move on, who is this research even for?

My aim is for this research to serve teachers, students, and developers. For teachers, it provides practical information on what learning outcomes to expect from using different PLTs and AI tools and connects that to relevant pedagogy and available curricula. For students, understanding PLT properties can identify which features best serve a diversity of needs. For developers, it highlights what product features and resources are most engaging and appropriate for learners and educators.

Understanding the PLT Framework

The PLT Framework defines branching forms of modality and materiality for classifying PLTs’ instructional properties. The framework challenges educators to critically think about how those properties affect learners’ experiences and their own teaching practice. It’s design draws from other pedagogical frameworks (i.e., Triple-E, UDL4CS, POUR, and TPACK), as well as my own research and testing.

Modality and Materiality?

Yes, another two terms I’ve adopted to describe my work. Their definitions are below, but you can read more about where these definitions originated in my specific projects on modality and materiality.

So, about that framework…

Right, right, of course. The framework consists mainly of two parts: (1) the definitions of modality, materiality, resources, and their subcomponents, and (2) a set of guiding prompts targeted at educators to consider how the PLT they are evaluating can and will be used within their learning environment. For ease of viewing, I’ve often formatted the prompts into a table called the “Technology Menu” because I themed it as if the educator is a food critic and the PLT is restaurant that they are “sampling” its properties at. That part is not required to use the framework, but it’s more fun, right?

Definitions

Here are the latest definitions of the PLT Framework. Please note that they have been updated in the past and will likely again as I continue to test the framework and get more data. If you have suggestions on how any of them could be improved, please feel free to contact me!

Programmable Learning Technology (PLT):

• The subset of CS edtech focused primarily on educating learners about CS concepts and practices.
  • These concepts often involve learning basic programming operations like declaring and using variables, conditional statements, functions, and classes.
  • Certain PLTs may cover specialized topics, such as complex systems, database structures, quantum computing, and more.

Artifact:

• A tangible or intangible unique expression created with a PLT during the learning process.
  • Artifacts reflect the functionality, capabilities, and intended use of the PLT(s) that produced them.
  • Artifacts are created using a PLT, but should be thought of as separate from the PLT.

Modality:

• The means of interaction between a user and a PLT.
  • The framework distinguishes two types of modalities: coding and feedback.

Coding Modality:

• How a PLT is programmed.
• Coding modality is not language specific.
  • In other words, the framework does not get into the differences between Python and Java or VEXcode VR blocks and MakeCode blocks.
  • “How” it is programmed does not refer to the physical interactions made to program it, but rather the user’s relationship to the code.
• Ex: block-based coding, text-based coding, AR tags, sequence coding

Feedback Modality:

• How a PLT conveys information to the user.
• PLTs may have multiple forms of providing feedback. Two very common ways include:
  • The PLT itself provides feedback on the success of operating it.
    • Ex: a program runs/fails to run in an online code editor, EarSketch does or does not generate music, or code succeeds or fails to upload to an Arduino.
  • An artifact created by the PLT is checked and evaluated by the user on its performance against its intended operation.
    • Ex: the program passes/fails unit tests, the music is listened to, or an LED on the Arduino lights up when a button is pressed.

Materiality:

• The composition of a PLT’s tangible and intangible materials, their properties, and how those properties support the integration of other materials.
  • The framework distinguishes two types of materiality: digital and physical.

Digital Materiality:

• Materials and properties that exist within the digital world.
• These can be online or offline.
• They are typically viewable or expressed through a screen.
• They can integrate other digital media, such as digital photos, music, writing, etc.
• Ex: applications windows, menus, virtual buttons, video players, canvases

Physical Materiality:

• Materials and properties that can be physically interacted with.
• These not only include devices such as robots, MCUs, and circuit components, but also the properties of devices used to interact with digital materials, such as computers, tablets, and screens.
  • Some PLTs may make use of alternative methods of interacting other than through a mouse & keyboard, such as touchscreen, cameras, other sensors, or assistive technologies.
• They can integrate other physical media, such as crafting materials, electronic peripherals, etc.
• Ex: keyboard & mouse, computer, tablet, robots, cameras, sensors, MCUs, circuit components

Core Resources:

• Resources for understanding the functionality of a PLT.
  • They can include Code APIs, Wikis, and other information on how to operate, write code, and receive feedback from a PLT.
  • They can include written, audio, or video tutorials.
  • They may exist within or apart from the PLT itself.
  • They can be made and/or managed externally by others that did not create the PLT.
  • If core resources are poorly designed, it might disincentivize a teacher from using the PLT.
• Ex: code repository APIs, tooltips, user guides, basic tutorial videos

Supplementary Resources:

• Resources that provide support to using and learning with a PLT.
  • They can include pedagogical content ranging from single activities with the PLT to full curricula.
  • They can be made and/or managed externally by others that did not create the PLT.
  • They may enable a learner to practice using the PLT without an instructor.
  • If supplementary resources are poorly designed, it might disincentivize a teacher from using that resource, but not necessarily the PLT itself.
• Ex: sample activities, curricula, videos on specific/niche PLT applications

The Technology Menu