Now is the time for the Josie Malaze.
And he speaks about breaking the code of inclusion.
The designing micro-material is based on prime principles for accessibility, programming, education.
Very difficult detail.
So, okay, the stage is yours.
Thank you.
Thank you. So, my name is Josie.
Okay, okay, okay. My name is Josie. I am a PhD student at the University of Bristol.
And today I'll be giving a talk about how we can design more open.
Sorry for that.
Okay, okay, okay. Test. All right.
So, I'm Josie.
And I'll be giving a talk about how we can design more open and inclusive pedagogical material to teach programming.
I'll first like to start a bit with a small introduction to tell you why we think this talk is important.
So, I've always been passionate both by programming, but also by education.
I joined Kododojo from a very young age, helping kids to learn how to code.
And I also went for an internship abroad in Kenya to build software for schools in less fortunate areas,
where I could first-hand experience what technology can do to help education.
Upon graduating, I joined Hack the Future Belgium for those of you that don't know.
It's a small nonprofit organization in Brussels that organizes coding boot camps for refugees
that are trying to find a job in the tech sector here.
So, before we go on to the meat of the presentation, let's take a look at some of the background information we need.
I'm pretty sure most of you remember your first programming classes where you had to install a weird-looking editor with hundreds of buttons.
You had to type in some text. You tried to press the pre-button or a compile button.
And you would see a weird error message that you didn't really understand.
This can be very demotivating.
And it's actually even worse when it happens to people from already underrepresented groups,
because if they encounter these types of errors, they internalize it,
and they feel like it's a confirmation that, yes, maybe they do not belong in such a classroom,
which is, of course, not the message you want to send.
Now, in the past years, there has been a new methodology of teaching programming
that tries to limit this issue, and it's based on the prim principles.
Now, the idea is, instead of starting to write your program from scratch from day one,
you basically start with a simple exercise, predict.
In this stage, you look at some existing code, you download it,
and you're going to try to predict what will the result be if I run this piece of code.
Then, in the next stage, you're actually going to download the code and execute it,
and going to verify, wow, were your predictions correct or not.
Then, in the third stage, we're going to ask you to actually make exercises on the problem.
This can be label all the variables, or can you tell me which variables are updated at some point in the code.
Now, up until this point, the learner hasn't changed anything about the code itself,
and as such, it also doesn't feel like it's a personal failure if something goes wrong in the process.
We're going to try to change this in the fourth step, modify,
where we're still not going to ask the student to write codes from scratch,
but we're going to give them a functioning program,
and we're going to ask them, like, hey, can you make some small modifications,
like, instead of running this loop three times, run it six times.
And it's only in the last stage where we're going to ask them to actually write a new program from scratch
using the same principles he developed earlier.
Now, this is a new methodology in teaching, in programming education,
but it's based on a very well-known pedagogical concept called the zone of proximal development,
where the idea is quite simple.
If you're only doing tasks you can do by yourself, you're not actually learning anything,
you're just repeating stuff.
But if I give you a task that you cannot do yourself,
even with some help, you're actually just going to get demotivated
and lose all motivation to continue learning, so that's also not good.
So we should always strive to give exercises in this yellow zone,
where the student cannot easily do it on their own,
but with some proper guidance they can get there.
Which brings us to micromaterials.
Now, a micromaterial is an open education resource,
so anybody can easily include it in their curriculum,
but it should also provide some sort of automated feedback,
so that even though the teacher is not there directly to guide the student,
they can still get something away from it.
Ideally, you also want some kind of automatically generated content,
because managing all the content for exercises can be a very time-consuming exercise for teachers.
So now we'll discuss some small examples that we, within our lab,
have built to experiment with these ideas.
So the first sample we'd like to discuss is an online environment
to practice the use of HTML.
It's designed for engineering students,
where we do not really expect to be able to develop HTML websites on their own,
but they should be able to grasp the core concepts of what the elements are about.
So we have a stepwise progress that they can follow level by level,
and we always start with a small presentation of the core HTML concepts that they need to know.
Now, once it's time to actually practice their HTML,
we do not just give them an editor,
but instead we make use of Google's Blockly library
to show this kind of HTML blocks that already contain the syntax,
so they can focus on what the text represents and not on the syntax itself.
Important here, we analyze sample HTML code to generate the blocks,
so adding new levels is as simple as providing a new website we want them to recreate.
We also dynamically create links for every element,
like hints for every element that they will need to use in the page.
We have a similar environment for the practice of databases for the same engineering students.
We used to have a lot of problems where they had to install databases locally,
database files could get corrupt, and they could turn into issues.
So we developed a fully online environment with the use of SQLJS,
which is an open source project based on SQLite,
compiled to WebAssembly using Unscripted.
So in this simple application, they would get to see a description of a database,
and on this database, they would get to run queries.
The queries would be typed in into an online code editor based on Adam.
So they get syntax highlighting, they get code completion,
and whenever they were to execute the queries, they could see the results directly in their browsers,
and this they would use to answer questions about the data.
Similarly, if it was more about inserting or updating the data,
we could no longer do with simply having a simple filling the answer type of question.
So instead, we're going to run checks to see at which step did they fail,
so they can stepwise go back and modify the code until they get it right for all the constraints.
Similarly, as well, if they want to create new tickets, we would also generate test cases for those.
Another problem that's very often looked at is can the students interpret codes.
And a common tool for this are trace tables.
Now, for those of you that don't know, a trace table is just a way, for example, here,
where you can look through your program line by line and note down what happens at each line.
For example, this trace table is designed to look at which variables are declared or initialized
or updated at certain moments in time.
A different type of trace tables would be the operator's trace table,
which gives the student a view of which operators are used at which points in the program.
A third one would be this variable values,
which is basically a way to see which variables are updated at which point in time,
which is a way that we can know is the student actually reasoning about his code correctly.
Lastly, we have a very basic trace table for advanced users
where they can just keep track of the latest state of the program.
Now, to this trace table application, we added some export functionalities
so teachers could import the JSON from the students
so we could run some diagnostics to see if students were understanding the code correctly.
Now we add more of a social game, a coding card conundrum.
It's basically a kind of card game where there are three types of cards.
We have goal cards that say in a certain condition that needs to be true.
We have environment cards that initialize five variables and we have code cards
that would execute some codes to update the global state of the program.
So it's a multiplayer game. It can be played from one to four people.
And we get this field where each player gets a handful of cards
and there will be three heaps in the center.
Now, during their turn, students could select a card from their hand
and place it on one of the environments.
When doing so, they would have to update this state table
to reflect the new latest state after executing the code on their card.
And if they managed to achieve the goal on their goal card,
they would get awarded some points for it.
So it's a social game where they can still practice their trace tables.
Then the final one we're going to discuss is Kingscrawl.
In here, we tried to make it a bit more silly.
We added a fantasy theme where the idea was that we live in the kingdom,
but the kingdom is going to be attacked by an evil dragon.
And it's up to us to find out which of the heroes will be able to stop the dragon.
Now, there are 16 heroes randomly generated
based on four essential variables of the equipment they are wearing
and two extra variables to increase the inclusiveness of our application.
Students would be shown a scroll that would be randomly generated
based on essential JavaScript features
that would update the states of those four variables.
And it's up to the students to predict after the program has run
which of the heroes matches the final description.
Students were able to automatically select which elements of JavaScript
they know or didn't know, so they could always participate
even though they hadn't seen everything.
And we gave them a state table to, of course,
keep track of the state changes as they went through the scroll.
So those were some of the examples that we developed.
But now we'd like to take a step back and look at what did we learn from it
and what kind of guidelines can we give you
if you were to try to implement something on your own.
So the first piece of advice you would like to give you is embrace the themes.
I know it might look silly at first, but just having a silly theme
takes a lot of the stress away from students
and they no longer feel like they can fail doing an exercise
because they're just playing a game in this kind of theme world.
But when we want to design those themes
we also shouldn't forget the principle of scale transfer
which basically states that the context in which you learn something
is an important part of how you will be able to apply those skills in different contexts.
So the closer your environment is to a realistic use case
the more useful their skills will directly be
when they need to apply them to a realistic environment.
So it's still good that in your silly theme world
there is a real life kind of application.
Also definitely invite the social aspects.
One of the main reasons people stop learning how to code
is because they don't really feel like they belong in the world
or they feel discouraged.
And just having this kind of social aspect
it can be slightly competitive but also collaborative
really takes away this barrier
and pushes people to continue learning in a welcoming environment.
Also you should strive to keep the setup minimal as possible
and I know this sounds really straightforward
but when you're designing an application that needs to be installed on a desktop
and even 2 out of 20 students are facing issues
that takes away at least 5 minutes of the teacher's time
that they cannot be helping students.
So if at all possible try to make it work just within the browser.
Now we should also make sure that our micro materials
only focus on one specific learning goal.
A lot of content is created like for example the Heidi programming language
which there is a great talk tomorrow
and these are all like great tools
but they kind of expect you to focus on them for your whole semester.
A lot of teachers already have a curriculum they need to follow
so they do not have the flexibility to really go with something else.
Your tools should really be something they can introduce
and use in one or two of their lessons
without needing to change their overall curriculum.
Otherwise it will just not be adapted.
We also have the expertise reversal principle.
Now the idea here is if you're new to something
you really like to be guided and get all the hints on
what can I do, what shouldn't I do
but as you gain more experience
if you keep having to go to the same guidance
it actually becomes a hindrance.
So ideally your application should be designed
in such a way that they contain multiple layers
where first at the outer layer there is a lot of help available for your students
but as they move on and become more experienced
and become more experts
they can take away those layers and start operating the tool
without getting all that extra help that's getting in the way of learning.
Also of course try to do something with automatic content generation
whenever you try to develop a tool on your own
you will quickly discover that having to update the content yourself
or even asking teachers to create the content themselves
it takes a very long time and they will not do it.
All right these to make it easier for teachers to use those tools
not to give them more work.
So the final principle is if adult possible
try to make things more well compatible
especially with the adults I've been teaching
they are very busy work lives
they are trying to learn programming while still taking care of the families
if they have a simple tool they can use
for example while on public transport
that's a huge quality of life improvement for them.
So let me finish this presentation by telling you all
I know you're all a community of builders
if you think like hey these kind of tools you discussed
I can build those
feel free to reach out to any learning environment
close to you and try to ask how you can contribute.
Thank you all for listening.