How can programming be taught to designers
Product development teams are getting more interdisciplinary. With that arises the need for better collaboration amongst team members that belong to different disciplines such as designers and developers. For better communication, it would help if the designers, at the very least, could functionally converse about programming.
Surprisingly, there are only a limited number of tools dedicated for teaching programming to designers. Moreover, they have limitations.
My team(Charvi, Smruthi, Clayton) and I explored if there is a better way to teach programming to designers.
This was a mini-project for the Georgia Tech Educational Technologies. As we were pressed for time, we conducted limited primary research (structured interviews with designers) and relied heavily on secondary research (evaluation of existing tools) and learning science theories.
Insights from primary research
Different problem solving approach: During our interviews, we realised a difference in problem solving techniques amongst designers and developers. Programmers break down the problem into smaller ones. It is associated to computational thinking. Designers work on a problem as a whole iteratively, often not knowing what the end would be.
Learning visually: Designers have a preference for learning visually.
We further studied existing tools and approaches for teaching programming evaluating there focus on computational thinking and visual learning.
Insights from secondary research
Processing: It is one of the prominent tools for teaching programming to visual and spatial learners. It is a text based programming language (wraps around the cumbersome Java syntax). It is a good visual learning tool but doesn’t teach computational thinking.
University Courses: Some universities have developed specialised courses. They combine traditional teaching techniques (in-class lectures, projects) with a specialised programming tool.
For instance, Georgia Tech’s Computer as an Expressive Medium aims to teach computational literacy through video game programming. The original class was taught in Java. The overhead of using Java was so high that it interfered with the students’ ability to learn the core programming concepts. Later they switched to using Processing.
AdMoVeo is a similar curriculum at Eindhoven University of Technology. It is intended for industrial designers and involves programming robots. They found industrial designers related well to having their programming actions manifest through physical and visual interactions.
The courses do teach computational thinking. However, they are not scalable.
Based on the insights, we reformulated our research question.
How could we build a scalable system that could teach designers to think computationally through visual techniques?
Out initial focus was decomposition and algorithms. Our goals were to teach:
● Dividing a problem into sub-problems
● Writing algorithms and pseudo-code
● Translating pseudo-code into code
● Program execution flows (conditional and iterative)
We conceptualised a web programming tool that leveraged learning science theories:
- Adaptive scaffolding
- Problem based learning
- Reduced cognitive load
- Learner centred design
The proposed tool would have multiple levels. Each level would have a programming problem and some hints (problem based learning). The problem are about printing different graphical patterns.
The learner starts with simple problems, the difficulty of problems increases and the level of scaffolding decreases with every level (learner centred design). The idea is to have the learner “struggle” to learn a new concept.
Level 1: Dividing a problem into sub-problems
Level 2: Write the Pseudo Code
The learners gradually progress from mashing up the existing pseudo-code to finally writing one from scratch. Lesser hints are given over time. (adaptive scaffolding)
Level 3: Translating pseudo-code into code
We wanted to build up on the existing knowledge of the user, hence there is an emphasis on starting with English like pseudo code and gradually progressing towards actual code. (transferability)
We wanted to not have the overhead of redoing the already mastered steps. A greyed out pseudo-code in the background helps the user focus on the syntax and not worry about decomposing the problem again. (reduced cognitive load)
Level 4: Understand program execution flows (conditional and iterative)
The tool would have debug sliders to walk the users through the execution of abstract code. The horizontal slider focusses on the iteration and the vertical slider focusses on the steps within an iteration.
Our goal was to only introduce learners to computational thinking. We thought of this tool as more of a precursor to Processing and other programming tools rather than a replacement.
As mentioned earlier, computational thinking has multiple facets to it — decomposition, pattern recognition / data representation, generalization/abstraction, and algorithms. The design concept touched upon decomposition and algorithms. Clearly, there is more work to do. :)
Though we couldn’t do heavy primary research, this was a good exercise to explore EdTech product concepts for solving a niche problem by leveraging existing learning science theories.
As with other projects, primary and secondary research helped reformulate the problem.