Connexion
Our free, browser-based Code Editor now keeps working when your internet connection doesn’t. If your connection breaks in the middle of a lesson or a project, you can carry on writing and running your code without disruption, even if the page is reloaded.
An unstable internet connection is a minor annoyance when you’re reading a web page, but it’s a much bigger problem when you’re 20 minutes into creating a program.
Until now, losing your connection while using the Code Editor could mean losing your work: if you refreshed the page at the wrong moment, you might have seen a blank screen or a browser error instead of your program.
When we wanted to understand better what learners and educators around the world need from the Code Editor, we carried out research in countries including India, Kenya, and South Africa. One topic we explored was the availability and reliability of internet connections in metropolitan and rural areas. While it was no surprise that internet access is often slow, unreliable, or expensive in rural areas, we learned that issues related to electricity supply, such as load-shedding and brownouts, are also prevalent in metropolitan areas. All this shapes what is realistically possible in a programming activity using an online editor.
And connectivity issues can occur in any school computing lab where 30 learners are all accessing the same WiFi at once, or for a Code Club running off a mobile hotspot in a community centre, or for someone finishing their homework on patchy mobile data.
That’s why it became a priority for us to improve the Code Editor’s offline support by making it resilient to disconnection.
As we describe in our recently shared draft principles for safe and responsible education technology, one of our commitments is to design for diverse needs, abilities, and contexts — including not to assume constant internet connectivity. This Code Editor update is a small, practical piece of that commitment.
The Code Editor was built with resilience in mind from the start, for example running code in your browser rather than on a server, and saving your project locally on your device as you go.
Our recent additions ensure that once you’ve opened the Code Editor while online, your browser holds on to even more of the parts you need to keep coding without a connection. Now if you go offline midway through using the Editor:
This update is built on a service worker, a script your internet browser runs in the background. When you first load the Code Editor, the service worker stores the files the Editor needs in your browser’s cache. If the network connection then breaks, the service worker serves those stored files instead of trying and failing to fetch them. When you come back online, it automatically refreshes the cache so you’re not left running old files.
The Code Editor isn’t a full offline app that you install. It’s a browser-based app that we have now upgraded to better cope with losing its internet connection, which means:
We’ll keep working to extend what parts of the Editor work offline.
The Code Editor works in your browser with no setup and will always be free for educators and learners. We hope this update makes it more useful for people in lots of different settings.
The update is one of those features some people will never notice, which is rather the point: it should feel like nothing went wrong. If your connection is unreliable and you try out the updated Code Editor, we’d love you to tell us whether or not it works well for you.
We would like to thank Cisco for the generous funding that made this work possible.
The post Keep coding when your internet drops: Offline support in the Code Editor appeared first on Raspberry Pi Foundation.
Millions of young people and educators around the world use our technology to teach, learn, and create with code. Building it safely and responsibly is intrinsic to who we are and what we stand for.
A growing body of research and public commentary links the use of social media, smartphones, and algorithmic platforms to declining mental health and attention in young people. Public attitudes are shifting in response, and parents, teachers, and governments are increasingly demanding action. Phone bans in schools and restrictions on social media are spreading across many countries. The technology sector can no longer take public trust for granted.
None of this is new territory for researchers, who have argued for decades that technology is not neutral, and that the choices made in designing it can either embed harm or help prevent it (1). We think this moment calls for a calm, evidence-led response, and we want to be open about how we are approaching it and to do this work alongside others rather than on our own.
We have always been a research-led organisation. When we face a difficult question, we look at the evidence and learn from the people who have studied it.
Children’s digital rights is a rich and well-established field. Researchers and experts have spent years thinking carefully about what children need from the technology they use, and how their rights apply in a digital world. The United Nations set out a clear framework in 2021 with General Comment No. 25, which describes how children’s rights apply to the digital environment. Organisations like UNICEF and the 5Rights Foundation have built on this with practical guidance for the people who design and build products.
This body of work gives us firm ground to stand on. Rather than starting from scratch, we have used it to shape our own approach. We have drawn in particular on UNICEF’s Responsible Innovation in Technology for Children framework, UNICEF’s EdTech for Good Framework 1.0, the UN’s General Comment No. 25, and the Digital Futures Commission’s Child Rights by Design principles.
We have begun by writing eight principles, designed to guide the decisions we make as we build and run our products.
Our principles:
1. The best interests of the child come first. We design for children’s wellbeing, which means more than safety and privacy. It includes their agency, their emotional health, their relationships, and the space to create. Sometimes putting that first means choosing against growth, engagement, or speed.
2. Our technology supports human relationships. It does not replace them. Any personalised or AI-supported features we build are there to strengthen the relationships between young people, educators, and caregivers. People stay in control, and we do not hand decisions about a child’s learning or wellbeing to a machine.
3. We only collect the data we need. By the time a child turns 13, more than 72 million pieces of personal data will have been collected about them. We collect the minimum we need to help children learn and to measure our impact. We do not sell data, and we never will.
4. We design for learning, and we prove its impact. Our products are grounded in evidence about how children learn, and we evaluate whether they actually work. We avoid designs that keep learners hooked rather than helping them learn.
5. We design with children and educators, not for them. The people who use our products are the experts on their own needs. We involve them in research, testing, and feedback, and we make sure what they tell us shapes the product, not just a report at the end.
6. We design for diverse needs, abilities, and contexts. Our technology adapts to people, not the other way around. We do not assume constant connectivity, confidence with digital technologies, or a classroom that looks like anyone else’s.
7. We are transparent and accountable. We use plain language to explain how our products work, how data is used, and what rights people have. And we give people clear ways to question or challenge the decisions our systems make.
8. We apply the highest standards of children’s rights everywhere we work. Where local rules fall short of international best practice, we choose the higher standard. A child’s rights should not depend on where they happen to live.
You can read the full set of draft principles, and the research behind each one, in this PDF:
Publishing these principles is a statement of intent, not a claim that we have got everything right. This is a fast-moving area. Regulation is changing quickly, the research keeps developing, and we grow and change our own products. There are areas where we know we have work to do, and almost certainly areas we have not yet spotted.
These principles are how we hold ourselves to account, and they are only a start. Alongside them, we are mapping the regulatory landscape across the countries where we work, developing ways to assess our products against these principles, and building these commitments into how we make decisions. We will keep listening to the people who use our products, and making sure children themselves have a voice in shaping the technology built for them.
We also know we cannot do this alone, so we have two asks for you:
If you have a view on these principles, tell us. Whether you are a researcher, educator, parent, young person, or policymaker, we want to hear where you think we have got it right, where we have not, and what we have missed. Honest challenge is genuinely useful to us. Give your feedback and sign up to be involved in shaping them.
If you are part of a non-profit or organisation working on similar questions, get in touch. We would like to build a coalition of like-minded organisations to share what we are learning and raise standards across the sector.
(1) See for example:
The post Building education technology that children can trust appeared first on Raspberry Pi Foundation.
Learning something new requires effort. Learners take in new information by listening and observing. When a lot of information is presented at once in a lesson, that can create too much cognitive load for learners — a barrier to understanding and engagement.
To help you design and deliver great computing lessons, we’ve written two new Pedagogy Quick Reads focused on Mayer’s Principles of Multimedia Learning. These research-backed principles give you practical strategies to lower your students’ unnecessary cognitive load during lessons, leading to better learning outcomes.
In this blog, we introduce the two new Quick Reads (Designing multimedia for clarity and Designing multimedia for understanding), which you can download for free to:
The blog also includes some examples for how to apply the principles in your computing lessons.
If you’d like an introduction to the idea of cognitive load, you can find the Quick Read about cognitive load theory here.
Mayer’s Principles of Multimedia Learning are practical principles that will help you create clearer resources and present information in a way that avoids unnecessary cognitive load for your learners.
Mayer’s Principles are based on three related facts:
Our first new Quick Read focuses on the following Mayer’s Principles for making your lessons as clear as possible, so that learners can connect the information they see and hear in real time.
Our second new Quick Read shares three Mayer’s Principles for how you can structure your lesson delivery to support your learners’ understanding:
We suggest you consider implementing Mayer’s Principles when you next design new lessons or want to adapt materials that you reuse regularly.
Here are some ideas on how you use both sets of principles in common computing teaching scenarios.
When displaying a new Python script or Scratch project, avoid adding long, written paragraphs of commentary to explain the code. Instead, place short text annotations or sub-goal labels directly next to the relevant lines or blocks. As you run through the code, use your pointer or live typing to guide your learners’ focus (signalling) and explain in words how the program works at the same time.
Before students move to a new topic, for example networking, consider what words or concepts your class needs to be familiar with. Allocate a few minutes at the start of your lesson for pre-training to introduce terms like LAN or bandwidth and how they relate to the lesson.
Consider how your lesson can be divided into stages to allow for better understanding (segmenting). Each stage should build on the previous one and feed into the next one. For example, when you explain how data moves across a network, you can introduce each step separately before combining them all into a complete model of a network.
Consider how you display visual information to your class. Ensuring related diagrams and labels appear close together, only include relevant materials and no decoration on your slides (coherence), and avoid simply reading out words on the slide identical forms of information (redundancy).
Mayer’s Principles are even more important for educators teaching multilingual learners or non-native speakers. When learners need to work harder to understand the language, poor lesson design can slow down their learning significantly.
Mayer’s Principles can help you with this challenge:
By intentionally designing and presenting lessons to give the right amount of information in the clearest way, you make it easier for your students to focus and build a lasting understanding of computing concepts. When your lesson materials align with how our brains process information, learners can build stronger mental models and approach independent learning activities with greater confidence.
Read our new Quick Reads to find out more and discover the research behind Mayer’s Principles:
The post How to design and present clear computing lessons appeared first on Raspberry Pi Foundation.
At this time of year, many educators are considering ways to update their content ahead of the new school term. Whether you’re a teaching assistant or head of department, it’s important to ensure that the content you’re updating — or even designing anew — is relevant and high quality, and meet learners’ needs. In today’s blog we’re highlighting ‘ABC learning design’, and how it can be used to rapidly design and improve learning experiences.
We also share our new ABC-focused Pedagogy Quick Read, which you can download for free to:
ABC learning design is a rapid, hands-on approach to design and develop blended learning experiences. The framework has traditionally been used at undergrad level, and had a lot of success when used in response to the global pandemic in 2020, when learning experiences had to quickly transition from being delivered in-person to being accessible remotely.
The model is centred around six learning types:
Before continuing, it’s important to distinguish between ‘learning types’ and the widely discredited concept of ‘learning styles’. Whilst learning styles refer to fixed characteristics or preferences of learners, learning types refer to different kinds of learning activities and pedagogical approaches that can be designed into a course.
These learning types are representative simplifications of pre-existing learning theories. For each learning type, educators can use different activities to deliver that type of learning. The activities will depend on your context and what’s right and applicable for your students.
How can I apply ABC learning design?
ABC learning design is often done in a team-based workshop setting (you can do it by yourself as well). Firstly, you analyse your existing content. Consider the goal of your current learning sequence, and assess how your learners are going to reach that goal with the different learning types.
By analysing existing content and activities, you can then identify what’s missing from your sequence. This allows you to build on existing gaps and consider different types of activities you could implement. You then create a set of learning cards, which help you to storyboard and plan your new learning sequence.
Learning cards are typically postcard-sized and colour-coded to one of the six learning types. Colour coding helps you to tell the cards apart, and to easily see which learning types are or aren’t included in your sequence.
Each card has the name and a short description of the learning type on the front, with examples of associated digital or in-person learning activities on the back. The learning cards:
ABC design can be contextualised to your classroom, practices, and school, and to the technologies you have available. For example, on the back of each learning card you could include a set of activities that have been tried and tested in, or approved by, your school. Alternatively, you could link to other frameworks or teaching approaches that work for you and your students.
Learning cards can also be used to collect other insights about teaching and learning within your context, and used as reminders of pedagogies to implement, as well as practical concerns. They can also help you to consider if there are opportunities for cross-curricular links within your learning sequence.
In a computing department, ABC learning cards can become a shared resource that give fellow educators an understanding of what’s possible. The cards can be used again and again to help plan future learning experiences.
By running an ABC workshop and creating these learning cards, you and your team will put together a contextualised learning sequence toolkit specific to your school and learners.
In our blog How to build young people’s agency through accessible learning, we explored the universal design for learning (UDL) framework. UDL aims to support educators to reduce barriers for learners. It helps educators to create learning environments that are accessible and effective for all learners by providing multiple means of engagement, representation, and action and expression.
Gormley et al. (2022) described an initiative to integrate UDL within ABC learning design. They developed adapted ABC learning cards where the reverse side included specific UDL prompts, in addition to the usual example activities. For example:
By including these UDL considerations directly on the ABC cards, the design team ensured that accessibility and inclusivity were central to learning design conversations.
Adding UDL prompts to your learning cards is a fantastic way to help you design accessible learning sequences.
In 2020, during the pandemic, the Computing at School (CAS) Research Working Group worked with classroom teachers to apply ABC learning design in their own contexts.
Following some training, teachers analysed their existing classroom activities and then developed a range of suitable alternatives for remote learning, categorising them into low-tech, mid-tech, and high-tech options.
The different activity options were then added to their own sets of ABC learning cards and used to help adapt lessons for remote teaching. You can read more about the project and view example cards on the CAS website.
Potential benefits for educators:
Potential benefits for students:
If you’d like to find out more about ABC learning design, you can download our Quick Read for free.
You can also listen to a thought-provoking discussion on the topic between James Robinson, Carrie Anne Philbin, Jane Waite, and Matthew Wimpenny-Smith in season 1, episode 6 of the Hello World podcast: Could curriculum design be as simple as ABC?
The post How to rapidly design and adapt quality learning experiences for your students appeared first on Raspberry Pi Foundation.
We think computing or computer science (CS) needs to be accessible to all learners, and we know that teachers work hard towards this. Traditional CS approaches can lack flexibility, creating barriers to learning and excluding some young people. In today’s blog, we’re highlighting the ‘Universal design for learning’ (UDL) framework and how you can use it to make computing education more accessible to all your learners.
We also share our new UDL-focused Pedagogy Quick Read, which you can download for free to:
Everyone is different and has their own way of learning. What works for one young person may not work for the next. So why should we expect learners to be taught the same material in the same way?
Todd Rose, a contributor to the UDL framework, highlights the factors involved with a young person’s ability to engage and participate in learning. These include cognitive, social-emotional, family background and academic factors. He dispels the idea of an “average” learner, and instead suggests the concept of learner variability.
As educators, it’s important to consider that students will likely be at different stages of understanding, and a one-size-fits-all approach isn’t suitable. The UDL framework avoids this mindset and provides teachers with structured guidelines to design accessible lessons from the beginning.
The UDL framework encourages educators to provide flexibility for learners in three areas:
Two things are key while you are planning how to apply the UDL framework with your learners:
Multiple means of engagement — show learners different reasons for engaging in programming. For example:
Multiple means of representation — teach programming concepts in multiple ways. For example:
Multiple means of action and expression — teach with accessibility in mind. For example:
The UDL framework aligns closely with several key research-supported pedagogies that you can use for effective instruction in computational thinking and programming. For example, the pedagogy approach ‘Use-Modify-Create’ (UMC) can be paired with the UDL categories. The new Quick Read explores these connections in more detail.
Potential benefits for teachers:
Potential benefits for learners:
Our new Quick Read shares tips on how to best use the framework in your teaching.
We know there is a lack of representation within the field of CS. Our recent position paper ‘Why kids still need to learn to code in the age of AI’ and an episode of the Hello World podcast, ‘How can we empower girls in computing’ touched on this. Both highlight why it’s important that learners from all backgrounds are empowered to contribute their perspectives and experiences and shape the future with computing.
“The reality is that access to the opportunities to learn about computer science, programming, and coding has remained deeply unequal, both within and between countries. That has helped create a technology sector that doesn’t reflect the broad diversity of human backgrounds, perspectives, and experiences. And we are all living with the consequences.” – Philip Colligan, Mark Griffiths, Veronica Cucuiat
“If we don’t have a diverse range of people designing and implementing that tech, then we are going to come across issues.” – Becky Patel, Tech She Can, Hello World podcast”
By embracing the principles of ‘Universal design for learning’ and similar approaches, we can create a more inclusive and equitable learning environment in computer science for everyone.
The post How to build young people’s agency through accessible learning appeared first on Raspberry Pi Foundation.
In game design, freedom can lead to paralysis. But in the latest issue of Wireframe magazine, Stuart Maine explains how game pillars and the iron triangle will help you focus on what’s important.
This article will cover two game development tools that are designed to help decide what’s important in the game you’re making. The iron triangle revolves around the practical realities of making a game, while game pillars cover the creative side, but both relate to the importance of focus. Let’s begin with pillars.
Every game media has its strengths, such as wargaming’s communities, the shared experiences of board games, or the collaboration of RPGs. One of the advantages of video games is their sheer flexibility – we can race across alien worlds, explore Egyptian tombs, or keep fit while going on magical quests. But that infinite flexibility can be a real problem for game creators, because if the game you’re making can include literally anything, then how do you know what to focus on?
Let’s assume you have an idea for a game based on a particular world or character, or a certain type of gameplay. Alternatively, you might have used player types (see Wireframe issue 39) to decide on a particular audience and the features they like, or if you’re working with someone else’s IP, then that brand’s owners might have a type of gameplay in mind. Game pillars help move beyond those starting points and guide you through development.
A game’s pillars are a list of around three ‘core statements’ created early in that game’s development. You could come up with your pillars before you’ve started development to help narrow down the possible game you might make, or you might do this after prototyping has given you an idea you want to pursue. You can even retroactively create pillars to help rescue a game that’s been in development for a while and has lost its way.
It’s easy to write ‘our game will feature 2D puzzles and platforming’, and technically that is a pillar because you can refer back to it later. But it doesn’t really say anything about what that platforming is for. By that, I mean why are you making a game about platforming? To dig deeper into the ‘why’ behind your pillar, you could rewrite that sentence to one of these:
Those are my example guesses at a pillar each for the platform games Flashback, Spelunky, and Celeste. All are 2D platformers, but they’re ‘about’ very different things.
Note that none of the above examples specifically talk about the gameplay being platforming, because pillars should focus on the feelings and emotions you want your game to evoke, rather than how you’re going to do it. That’s because pillars aren’t a feature list to check off, more a tool to help remember the things that are important when you’re submerged in the day-to-day realities of game development. Pillars are the why of your game, and the actual development process is coming up with the what to match those initial goals.
Print your chosen pillars as large as you can and put them up somewhere you’ll see them every day. That way they’ll become ingrained in your thoughts and you’ll easily be able to refer to them when someone suggests a new feature or change to the game. Will that change help bring your game closer to your pillars (great), not really affect them (neutral), or work against them (bad)?
I’ve seen studios use pillars on struggling games to discard any areas which don’t match them. You particularly see this if a game is taking too long to release (because most professional studios have to get a game out to some sort of deadline – more on this below), with people looking back to their pillars to help work out what to cut. If feature A is cool, but feature B aligns with the pillars, it’ll take a strong argument to keep A.
There are a couple of approaches for coming up with a game’s pillars, each with advantages, but also potential problems to look out for. Both of these approaches assume you already know to some degree what the game will be. Your pillars will help guide the eventual game’s details, but they’re a tool for staying on track as you forge ahead, not for coming up with ideas in the first place. If you haven’t agreed on a concept for your game yet, then run game jams, conduct audience and market research, or paper prototype ideas first.
Second, both approaches assume any business, audience, IP, or technology factors are already agreed and set in stone. For example, you might already know that this will be a multiplayer game, that it must be released within this time frame, or that it must be built on the technology created for your previous game. We’ll talk more about this with the iron triangle, but basically, any real-world issues that are beyond your control must be acknowledged or you risk coming up with pillars that set you up for difficulties later.
The two approaches are to have the entire team brainstorm potential pillars, or have vision holders dictate them:
ONE: If the entire team is involved, then you run brainstorming sessions where everyone’s potential pillar ideas are stuck up on a wall. Then the group chooses the best pillars or combines a couple of ideas into pillars (remember the point about keeping them short – mashing many ideas into a long pillar is cheating).
The advantage of this approach is that everyone understands and buys into the chosen pillars because they had a say in creating them. The downside is that this process can take time, with potentially conflicting ideas needing to be whittled down until an agreement is reached.
TWO: The other approach is for ‘creative vision holders’ to come up with the game’s pillars and then present them to the rest of the team. Obviously, this is much less collaborative and more about saying, ‘I have a vision for this game which I think could be incredible, will you help me make it?’ The advantage of this is that everyone can rally behind a singular vision that someone is passionate about bringing to the world. As a result, the game’s pillars are likely to be extremely focused and all pointing in the same direction. The downside is that it requires everyone else to get on board with the game’s pillars even though they didn’t help come up with them.
Either way, once the pillars have been created, everyone on the team has to work with them in mind – there’s an implied contract that these rules must be enforced to ensure the game keeps moving in the right direction. Even though it can be unpopular to say no to someone’s idea, that’s what pillars are there to help with (and of course, pillars don’t say ‘that idea is bad’, simply that it doesn’t fit this particular game. Write the idea down and maybe build your next game around it).
Here are some actual pillars from games I’ve worked on:
I realise that game pillars are quite an abstract topic, but in my experience across many games and studios, they have proven their worth. At the start of a project, they help avoid the ‘blank page’ problem of being able to make anything you can imagine, and later they help you say ‘this, but not that’ and avoid wandering in the development wilderness. So however you choose to structure or word your game pillars, I wholeheartedly recommend spending a little time thinking about the why before you launch into the what.
Speaking of which, let’s take a look at the iron triangle and how it will impact your game, because no matter what you do in the games industry, the triangle will impact you. As a result, it’s important to have an idea of how it works and what it means to your projects. A quick disclaimer: I’m going to simplify a complex area for space reasons, so if it interests you, check out online resources on this and other project management topics.
Have you ever played a game and clearly seen that it was unfinished? Missing features, obvious bugs, and a lack of polish show that you’re playing a game that needed more development time. The iron triangle is the reason games are released in an unfinished state, but it isn’t some malevolent force – it’s simply where reality butts up against creativity in game development.
Coined by Dr. Martin Barnes, the triangle applies to premium games as much as free ones, and to indie games as equally as blockbusters. It relates to…
Now we know the three points of the iron triangle – where things get interesting is that those points are all interrelated, and the rule is you can only control two of the three points. You can select which two points you want to control, but you have no say on what happens to the third. That’s why it’s called an iron triangle – the outcome of the third point is decided by what you do with the two you’ve chosen to control.
These are the outcomes you can expect based on the two points of the triangle you choose to control:
You might be wondering why any of this matters – after all, you could be making a game in your spare time or working at a studio where other people make these decisions. But if you understand which of the points of the triangle your project is trying to control, then you can work more effectively, making choices that work towards those needs rather than against them.
As a side note, if you’re working at a studio and whoever’s in charge insists they can control all three points of the iron triangle, consider that a Big Red Warning. That sort of denial of the fundamentals of project management means overtime – and a game that’s likely to go off the rails.
The iron triangle isn’t about hateful business realities quashing your creative dreams, it’s about choosing and understanding your priorities so that you control your game, not the other way around.
To recap: choosing your game’s pillars helps you focus on what’s important, and choosing which two points of the iron triangle you want to control helps you focus on the reality of making a game. Both of these are important, because not deciding on a game’s pillars can lead to the end result being a mess of conflicting ideas pulling in multiple directions, and ignoring the iron triangle leads to games spiralling into overtime, delays, and impossible demands. Yes, making games should be fun, but a little focus early in a project’s life can pay off big time later on.
You can read more features like this one in Wireframe issue 52, available directly from Raspberry Pi Press — we deliver worldwide.
And if you’d like a handy digital version of the magazine, you can also download issue 52 for free in PDF format.
The post How pillars and triangles can focus your game design appeared first on Raspberry Pi.
After a brief hiatus over the Easter period, we are excited to be back with our series of online research seminars focused on diversity and inclusion, where in partnership with the Royal Academy of Engineering, we host researchers from the UK and USA. By diversity, we mean any dimension that can be used to differentiate groups and people from one another. This might be, for example, age, gender, socio-economic status, disability, ethnicity, religion, nationality, or sexuality. The aim of inclusion is to embrace all people irrespective of difference.
This month we welcomed Dr Maya Israel, who heads the Creative Technology Research Lab at the University of Florida. She spoke to us about designing inclusive learning experiences in computer science (CS) that cater for learners with a wide range of educational needs.
Maya introduced her work by explaining that the primary goal of her research is to “increase access to CS education for students with disabilities and others at risk for academic failure”. To illustrate this, she shared some preliminary findings (paper in preparation) from the analysis of data from one US school district.
Her results showed that only around 22–25% of elementary school students with additional needs (including students with learning disabilities, speech or language impairments, emotional disturbances, or learners on the autistic spectrum) accessed CS classes. Even more worryingly, by high school only 5–7% of students with additional needs accessed CS classes (for students on the autistic spectrum the decline in access was less steep, to around 12%).
Maya made the important point that many educators and school leaders may ascribe this lack of representation to students’ disabilities being a barrier to success, rather than to the design of curricula and instruction methods being a barrier to these students accessing and succeeding in CS education.
Maya detailed the systems approach she uses in her work to think about external barriers to inclusion in CS education:
As an example, Maya pointed out that many of the programming platforms used in CS education are not fully accessible to all learners; each platform has unique accessibility issues.
This is not to say that students with additional needs have no internal barriers to succeeding in CS (these may include difficulties with understanding code, debugging, planning, and dealing with frustration). Maya told us about a study in which the researchers used the Collaborative Computing Observation Instrument (C-COI), which allows analysis of video footage recorded during collaborative programming exercises to identify student challenges and strategies. The study found various strategies for debugging and highlighted a particular need for supporting students in transitioning from a trial-and-error approach to more systematic testing. The C-COI has a lot of potential for understanding student-level barriers to learning, and it will also be able to give insight into the external barriers to inclusion.
Maya’s work has focused not only on identifying the problems with access, it also aims to develop solutions, which she terms pathways to inclusion. A standard approach to inclusion might involve designing curricula for the ‘average’ learner and then differentiating work for learners with additional needs. What is new and exciting about Maya’s approach is that it is based on the premise that there is no such person as an average learner, and rather that all learners have jagged profiles of strengths and weaknesses that contribute to their level of academic success.
In the seminar, Maya described ways in which CS curricula can be designed to be flexible and take into account the variability of all learners. To do this, she has been using the Universal Design for Learning (UDL) approach, adapting it specifically for CS and testing it in the classroom.
The UDL approach helps educators anticipate barriers to learning and plan activities to overcome them by focusing on providing different means of engagement, representation, and expression for learners in each lesson. Different types of activities are suggested to address each of these three areas. Maya and her team have adapted the general principles of UDL to a CS-specific context, providing teachers with clear checkpoints to consider when designing computing lessons; you can read more on this in this recent Hello World article.
A practical UDL example Maya shared with us was using a series of scaffolded Scratch projects based on the ‘Use-Modify-Create’ approach. Students begin by playing and remixing code; then they try to debug the same program when it is not working; then they reconstruct code that has been deconstructed for the same program; and then finally, they try to expand the program to make the Scratch sprite do something of their choosing. All four Scratch project versions are available at the same time, so students can toggle between them as they learn. This helps them work more independently by reducing cognitive load and providing a range of scaffolded support.
This example illustrates that, by designing activities that support students with additional educational needs, we can improve the understanding and proficiency of all of our students.
Maya identified three groups of teachers who can benefit from training in either UDL or in supporting students with additional needs in CS:
Maya and her team conducted research with all three of these teacher groups, where they provided professional development for the teachers with the aim to understand what elements of the training were most useful and important for teachers’ confidence and practice in supporting students with additional needs in CS. In this research project, they found that for the teachers, a key aspect of the training was having time to identify and discuss the barriers/challenges their students face, as well as potential strategies to overcome these. This process is a core element of the UDL approach, and may be very different to the standard method of planning lessons that teachers are used to.
Another study by Maya’s team showed that an understanding of UDL in the context of CS was a key predictor of teacher confidence in teaching CS to students with additional needs (along with the number years spent teaching CS, and general confidence in teaching CS). Maya therefore believes that focusing on teachers’ understanding of the UDL approach and how they can apply it in CS will be the most important part of their future professional development training.
Maya talked to us about the importance of intersectionality in supporting students who are learning CS, which aligns with a previous seminar given by Jakita O. Thomas. Specifically, Maya identified that UDL should fit into a wider approach of Intersectional Inclusive Computer Science Education, which encompasses UDL, culturally relevant and sustaining pedagogy, and translanguaging pedagogy/multilingual education. We hope to learn more about this topic area in upcoming seminars in our current series.
You can download Maya’s presentation slides now, and watch the seminar recording here:
The next seminar in the diversity and inclusion series will take place on Tuesday 4 May at 17:00–18:30 BST / 12:00–13:30 EDT / 9:00–10:30 PDT / 18:00–19:30 CEST. You’ll hear from Dr Cecily Morrison (Microsoft Research) about her research into computing for learners with visual impairments.
To join this free event, click below and sign up with your name and email address:
We’ll send you the link and instructions. See you there!
This was our 15th research seminar — you can find all the related blog posts here.
The post How can we design inclusive and accessible curricula for computer science? appeared first on Raspberry Pi.
In our brand-new issue of Hello World magazine, Hayley Leonard from our team gives a primer on how computing educators can apply the Universal Design for Learning framework in their lessons.
Universal Design for Learning (UDL) is a framework for considering how tools and resources can be used to reduce barriers and support all learners. Based on findings from neuroscience, it has been developed over the last 30 years by the Center for Applied Special Technology (CAST), a nonprofit education research and development organisation based in the US. UDL is currently used across the globe, with research showing it can be an efficient approach for designing flexible learning environments and accessible content.
Engaging a wider range of learners is an important issue in computer science, which is often not chosen as an optional subject by girls and those from some minority ethnic groups. Researchers at the Creative Technology Research Lab in the US have been investigating how UDL principles can be applied to computer science, to improve learning and engagement for all students. They have adapted the UDL guidelines to a computer science education context and begun to explore how teachers use the framework in their own practice. The hope is that understanding and adapting how the subject is taught could help to increase the representation of all groups in computing.
The UDL guidelines help educators anticipate barriers to learning and plan activities to overcome them.
The UDL framework is based on neuroscientific evidence which highlights how different areas or networks in the brain work together to process information during learning. Importantly, there is variation across individuals in how each of these networks functions and how they interact with each other. This means that a traditional approach to teaching, in which a main task is differentiated for certain students with special educational needs, may miss out on the variation in learning between all students across different tasks.
The UDL guidelines highlight different opportunities to take learner differences into account when planning lessons. The framework is structured according to three main principles, which are directly related to three networks in the brain that play a central role in learning. It encourages educators to plan multiple, flexible methods of engagement in learning (affective networks), representation of the teaching materials (recognition networks), and opportunities for action and expression of what has been learnt (strategic networks).
The three principles of UDL are each expanded into guidelines and checkpoints that allow educators to identify the different methods of engagement, representation, and expression to be used in a particular lesson. Each principle is also broken down into activities that allow learners to access the learning goals, remain engaged and build on their learning, and begin to internalise the approaches to learning so that they are empowered for the future.
| Multiple means of engagement | Multiple means of representation | Multiple means of action and expression |
|
Provide options for recruiting interests * Give students choice (software, project, topic) * Allow students to make projects relevant to culture and age |
Provide options for perception * Model computing through physical representations as well as through interactive whiteboard/videos etc. * Select coding apps and websites that allow adjustment of visual settings (e.g. font size/contrast) and that are compatible with screen readers |
Provide options for physical action * Include CS unplugged activities that show physical relationships of abstract computing concepts * Use assistive technology, including a larger or smaller mouse or touchscreen devices |
|
Provide options for sustaining effort and persistence * Utilise pair programming and group work with clearly defined roles * Discuss the integral role of perseverance and problem-solving in computer science |
Provide options for language, mathematical expressions, and symbols * Teach and review computing vocabulary (e.g. code, animations, algorithms) * Provide reference sheets with images of blocks, or with common syntax when using text |
Provide options for expression and communication * Provide sentence starters or checklists for communicating in order to collaborate, give feedback, and explain work * Provide options that include starter code |
|
Provide options for self-regulation * Break up coding activities with opportunities for reflection, such as ‘turn and talk’ or written questions * Model different strategies for dealing with frustration appropriately |
Provide options for comprehension * Encourage students to ask questions as comprehension checkpoints * Use relevant analogies and make cross-curricular connections explicit |
Provide options for executive function * Embed prompts to stop and plan, test, or debug throughout a lesson or project * Demonstrate debugging with think-alouds |
Each principle of the UDL framework is associated with three areas of activity which may be considered when planning lessons or units of work. It will not be the case that each area of activity should be covered in every lesson, and some may prove more important in particular contexts than others. The full table and explanation can be found on the Creative Technology Research Lab website at ctrl.education.ufl.edu/projects/tactic.
While an advantage of UDL is that the principles can be applied across different subjects, it is important to think carefully about what activities to address these principles could look like in the case of computer science.
Researchers at the Creative Technology Research Lab, led by Maya Israel, have identified key activities, some of which are presented in the table on the previous page. These guidelines will help educators anticipate potential barriers to learning and plan activities that can overcome them, or adapt activities from those in existing schemes of work, to help engage the widest possible range of students in the lesson.
As well as suggesting approaches to applying UDL to computer science education, the research team at the Creative Technology Research Lab has also investigated how teachers are using UDL in practice. Israel and colleagues worked with four novice computer science teachers in US elementary schools to train them in the use of UDL and understand how they applied the framework in their teaching.
The research found that the teachers were most likely to include in their teaching multiple means of engagement, followed by multiple methods of representation. For example, they all offered choice in their students’ activities and provided materials in different formats (such as oral and visual presentations and demonstrations). They were less likely to provide multiple means of action and expression, and mainly addressed this principle through supporting students in planning work and checking their progress against their goals.
Although the study included only four teachers, it highlighted the flexibility of the UDL approach in catering for different needs within variable teaching contexts. More research will be needed in future, with larger samples, to understand how successful the approach is in helping a wide range of students to achieve good learning outcomes.
There are numerous resources designed to help teachers learn more about the UDL framework and how to apply it to teaching computing. The CAST website (helloworld.cc/cast) includes an explainer video and the detailed UDL guidelines. The Creative Technology Research Lab website has computing-specific ideas and lesson plans using UDL (helloworld.cc/udl).
Maya Israel will be presenting her research at our computing education research seminar series, on 20 April 2021. Our seminars are free to attend and open to anyone from anywhere around the world. Find out more about the current seminar series, which focuses on diversity and inclusion in computing education.
In issue 15 of Hello World, we hear from five teachers who have made the switch to computing from another subject. They tell us about the challenges they have faced, as well as the joys of teaching young people how to create new things with technology. All this and much, much more in the new issue!
Educators based in the UK can subscribe to receive print copies for free!
The post Universal design for learning in computing | Hello World #15 appeared first on Raspberry Pi.
If you have one of our official cases, keyboards or mice, or if you’ve visited the Raspberry Pi Store in Cambridge, UK, then you know the work of Kinneir Dufort. Their design has become a part of our brand that’s recognised the world over. Here’s an account from the Kinneir Dufort Chief Design Officer, Craig Wightman, of their team’s work with us.
Over the last six years, our team at Kinneir Dufort have been privileged to support Raspberry Pi in the design and development of many of their products and accessories. 2019 has been another landmark year in the incredible Raspberry Pi story, with the opening of the Raspberry Pi store in February, the launch of the official keyboard and mouse in April, followed by the launch of Raspberry Pi 4 in June.
We first met Eben, Gordon and James in 2013 when we were invited to propose design concepts for an official case for Raspberry Pi Model B. For the KD team, this represented a tremendously exciting opportunity: here was an organisation with a clear purpose, who had already started making waves in the computing and education market, and who saw how design could be a potent ingredient in the presentation and communication of the Raspberry Pi proposition.
Alongside specific design requirements for the Model B case, the early design work also considered the more holistic view of what the 3D design language of Raspberry Pi should be. Working closely with the team, we started to define some key design principles which have remained as foundations for all the products since:
Whilst maintaining a core of consistency in the product look and feel, these principles have been applied with different emphases to suit each product’s needs and functions. The Zero case, which started as a provocative “shall we do this?” sketch visual sent to the team by our Senior Designer John Cowan-Hughes after the original case had started to deliver a return on investment, was all about maximum simplicity combined with adaptability via its interchangeable lids.
The ‘levitating lid’ version of the Zero case is not yet publically available
Later, with the 3A+ case, we started with the two-part case simplicity of the Zero case and applied careful detailing to ensure that we could accommodate access to all the connectors without overcomplicating the injection mould tooling. On Raspberry Pi 4, we retained the two-part simplicity in the case, but introduced new details, such as the gloss chamfer around the edge of the case, and additional material thickness and weight to enhance the quality and value for use with Raspberry Pi’s flagship product.
After the success of the KD design work on Raspberry Pi cases, the KD team were asked to develop the official keyboard and mouse. Working closely with the Raspberry Pi team, we explored the potential for adding unique features but, rightly, chose to do the simple things well and to use design to help deliver the quality, value and distinctiveness now integrally associated with Raspberry Pi products. This consistency of visual language, when combined with the Raspberry Pi 4 and its case, has seen the creation of a Raspberry Pi as a new type of deconstructed desktop computer which, in line with Raspberry Pi’s mission, changes the way we think about, and engage with, computers.
The launch of the Cambridge store in February – another bold Raspberry Pi move which we were also delighted to support in the early planning and design stages – provides a comprehensive view of how all the design elements work together to support the communication of the Raspberry Pi message. Great credit should go to the in-house Raspberry Pi design team for their work in the development and implementation of the visual language of the brand, so beautifully evident in the store.
An early sketch model of the Raspberry Pi Store
In terms of process, at KD we start with a brief – typically discussed verbally with the Raspberry Pi team – which we translate into key objectives and required features. From there, we generally start to explore ideas with sketches and basic mock-ups, progressively reviewing, testing and iterating the concepts.
Sketching and modelling and reviewing
For evaluating designs for products such as the cases, keyboard and mouse, we make considerable use of our in-house 3D printing resources and prototyping team. These often provide a great opportunity for the Raspberry Pi team to get hands on with the design – most notably when Eben took a hacksaw to one of our lovingly prepared 3D-printed prototypes!
EBEN YOUR FINGERS
Sometimes, despite hours of reviewing sketches and drawings, and decades of experience, it’s not until you get hands-on with the design that you can see further improvements, or you suddenly spot a new approach – what if we do this? And that’s the great thing about how our two teams work together: always seeking to share and exchange ideas, ultimately to produce better products.
There’s no substitute for getting hands-on
Back to the prototype! Once the prototype design is agreed, we work with 3D CAD tools and progress the design towards a manufacturable solution, collaborating closely with injection moulding manufacturing partners T-Zero to optimise the design for production efficiency and quality of detailing.
One important aspect that underpins all our design work is that we always start with consideration for the people we are designing for – whether that’s a home user setting up a media centre, an IT professional using Raspberry Pi as a web server, a group of schoolchildren building a weather station, or a parent looking to encourage their kid to code.
Engagement with the informed, proactive and enthusiastic online Raspberry Pi community is a tremendous asset. The instant feedback, comments, ideas and scrutiny posted on Raspberry Pi forums is powerful and healthy; we listen and learn from this, taking the insight we gain into each new product that we develop. Of course, with such a wide and diverse community, it’s not easy to please everyone all of the time, but that won’t stop us trying – keep your thoughts and feedback coming to RPifeedback@kinneirdufort.com!
If you’d like to know more about KD, or the projects we work on, check out our blog posts and podcasts at www.kinneirdufort.com.
The post Designing distinctive Raspberry Pi products appeared first on Raspberry Pi.
We want to improve the way we support companies that design with Raspberry Pi computers, and we need your help to do it.
Raspberry Pi’s success is thanks to the community that exists around it. When we launched Raspberry Pi 4, our most powerful computer yet, we gave our community the chance to ask our engineers all about the new product.
Now we’d like to turn the tables and ask you some questions as we work to improve the support we offer to people and organisations that design using Raspberry Pi.
If you have experience of designing products or industrial solutions that use Raspberry Pi, we would love to hear from you.
Raspberry Pi has been used to power products from Compute Module-based industrial controllers made by Kunbus…
…to Raspberry Pi-based washing machines with Raspberry Pi touchscreen displays from Marathon.
Organisations are increasingly using various kinds of Raspberry Pi computer to power products and solutions, and we want to do more to support designers.
If you have experience as a design consultancy that uses Raspberry Pi computers in products, or if you have used a designer to build a product that includes a Raspberry Pi, we would love to talk to you about it. You will help shape what we offer in the future, and make designing products with Raspberry Pi simple, quick, and powerful.
If you use Raspberry Pi in products or in industrial solutions, I want to talk to you. Please fill in this form with a few details of your experience so we can talk more.
The post Help us make it easier for you to design products with Raspberry Pi appeared first on Raspberry Pi.
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 