03 - On Technical and Digital Literacy skills

Developing Digital Literacy skills

The process of creating a pixel art characters and hazard involved using an online grid design tool called Piskel, creating an design of an appropriate size, saving, exporting as an image, downloading to the hard drive of the laptop in use and finally uploading and incorporating the image into the code project and linking using code syntax.

To integrate new gameplay design patterns or adapt existing ones in their games, participants needed to develop unfamiliar technical processes associated with computer coding, as well as foundational digital skills related to using a desktop personal computer. One example of a skill developed by many participants was proficiency in keyboard and mouse use. Combined with the ability to navigate internet browser tabs, this facilitated movement between computer code, game prototypes, and supporting web-based documentation.

The process of collating these skill aligned to curricular concepts above or those explored in computing research as desirable in a manageable list involved excluding a large number of relevant skills that were being developed as part of the game making activities. In particular key digital literacy and basic skills associated with using a desktop personal computer which were developed are listed below.

• Keyboard use: in particular use of shortcuts including Cntl + C, Cntl + V and the use of Shift and arrow keys to highlight text
• Mouse use: building proficiency with accurate mouse use and the process of clicking and dragging
• File management: downloading and locating digital files on a desktop environment
• Exporting graphical assets: locating the proceedure for exporting files from applications for use on other applications in the correct (interchangeable) format.
• Using web browser tabs: creating new tabs and navigating between different browser tabs as part of a iterative design process.
• Use of graphical editing tool sets: for example drawing pencils, fill buckets, eraser tools.

On patching & debugging

Transcript of interaction explaining code patching

The following is a transcript…

So if you click on that (referring to tutorial link) if you want to add a moving enemy.

I’ve tried to put a bit like that (referring to illustration below on code patching). What that means is, you’re looking for that bit of code at the top. And you’re going to copy it and paste it into that bit at the bottom. Where it says Playstate.preload. That’s the part of the code that you need to put it into. Just to make it a bit clearer.

{ width=80% }

Madiha: So you’re not cutting the bit at the top out, in red. You’re using that bit instead of the yellow bit.

Mick: Well actually, you’re putting it inside of it. So here you would copy it and in your code example. You then look for that bit where it says preload. You then put it inside of it at the bottom of that.

Madiha: So just insert it somewhere.

Mick. Yeah insert it. So here we’ve got different parts of our game. We’ve got preload. We’ve got create. And we get used, we start to get used to finding them. In this one it’s preload that’s the one that its saying we should put it inside of. And then this next bit. It’s saying, ah, you should put that into your create function.

So we’re moving in the right direction. But any other things where you think. Ah that could be easier. Let me know and I’ll try to make these resources much easier.

Mick: It’s almost like this is our control panel. What do you want to do next and we jump off from there. And I’ve put it down on a bit of paper. It’s just gcc-examples.glitch.com

Debugging GDPs used to nurture tactical responses to coding errors

COPIED FROM GDP CHAPTER

Additionally the key affordances of the learning design including the starting template code snippets and the resulting code patching process appear to encourage the creation of glitch errors (Appendix Debugging).

Solving / Debuggging code problems that responses are helped by the high level of context present in the use of GDP as a structural design framework.

In critique of online tutorials researchers note few provide common errors [@kim_pedagogical_2017]. While it seems reasonable not to include all possible errors, the challenge of supporting participants to build skills and effective repertoires involving debugging is widely recognised [SUPPORT]. My observations suggest that the close coupling of code implementation and target behaviour aids participants in debugging and also be profitably can be drawn on by facilitators.

In analysis of journal notes and recorded screens I began to identify different kinds of coding problems that blocked participants from progressing and build proficiency and flexibility in addressing them. Reflections on participant experiences of kinds of errors are explored in Appendix.tech.2. In the appendix I reflect on syntax errors which stopped the game from working entirely, bugs where code changes had no effect on the game and glitches which don’t crash the game instead creating an unintended effect. Glitches merit a summary here as a particularly interesting site of guided participation. In my reflective notes I propose that glitches are more motivating to correct than other errors.

Aspects of the design, use of a starting template and supporting resources based on code snippets and thus code patching process increased appear to encourage glitch bugs. See Vignette 1 for an example of a glitch bug which provoked further investigation and hand on tinkering. A diversity of helping strategies evolved, my own and those of others, in response to errors. For my part, these altered when I judged when participants to be receptive to different forms of input. Glitch errors were often embraced as curiosities and as a learning opportunity to understand the related code and associated abstract concepts using a concrete example afforded by the mechanics of the game design pattern. Mirroring the proposition of half baked games theory that a incomplete / templated game are motivates initial participation, my observation support a position that glitch bugs, which move game into a broken state also provide motivation. Additionally, as the bug relates to a targeted GDP which is closely coupled with a suggested code solution and tutorial, this process incorporates the benefits of a just-in-time approach to supporting documentation

This area opens some interesting lines of questioning which are beyond the full remit of this research but are included in Appendix.tech.2 as promising areas for future work. When addressing issues of motivation and efficacy a different research methodology would be needed.

This section highlights different possible errors and notes that responses are helped by the high level of context present in the use of GDP as a structural design framework.

On Patching

More on patching and interaction with debugging.

and interaction with UMC process.

On different kinds of errors

In analysis of journal notes and recorded screens I began to identify different kinds of coding problems that blocked participants from progressing.

In critique of online tutorials researchers note few provide common errors[@kim_pedagogical_2017]. This lack of problem solving techniques communicated in online tutorials may addressed through use of GDPs.

Professionals build up this sense through experience. While some practices are taught many others become ad-hoc rules of thumb that are difficult to communicate in abstract ways.

More research would be welcome on how to help learners pick up these understandings. Further analysis of the different kinds of errors that are likely to arrive and testing different strategies for dealing with them that take into account the zone or proximal development of the participants may provide not only useful input for the participants, but also opportunities to check understandings of processes and game patterns and computational patterns in use.

For example, on into the detail and types or errors. These include:

• Syntax and Program Errors are errors in your code which stop the game from functioning at all, often resulting in a blank screen.
• No Behaviour Bugs are errors which in your code which don’t stop the game from functioning but your intended effect is not present when it should be.
• Glitches don’t stop your game from running but as you play you see that there is an unintended effect. The game does something different from what we want it to do.

NOTE - Perhaps explore glitch examples.

This area show potential but is under explored. However, just surfacing the issue feels valid in terms of useful stream of facilitator practice to explore.

Concluding remarks on debugging and revision

Many participants spent significant periods of time improving, testing and fixing coding errors in their games. Analysis of the coding of video data showed that revision and debugging was often a solo effort. In a way that mirrors the spread of other creative technical processes, certain revision and debugging practices that were transmitted through interaction with the facilitator that were adopted and used by the community. Some practices were straight-forward, for example the swift navigation between the source code window and a preview window of the live game. Others were more specialist like the use of the developer console of the internet browser to debug JavaScript errors or the process of hovering over red dots in the code playground to explore error messages.

The experience of debugging appears to be a particular practice evoking certain feelings. Feelings of frustration alternate with elation at solving a tricky bug.

As I built proficiency as a facilitator I began to identify different kinds of errors. The use of code patching often provoked glitch bugs which where actually behaviour did not match intended behaviour. In analysis of interactions with participants when trying to solve coding blockages, I note different strategies in responding to such errors. For some participants I quickly solve them with short explanation to allow them to continue. For other participants who I judge to be receptive I may celebrate the glitch and explore with them the opportunities they provided to understand the related code in a way that allowed the exploration of more abstract concepts using a concrete example afforded by the mechanics of the game design pattern.

The following example provides an illustration of this kind of interaction and examines the surfacing of computational thinking concepts in particular. FIND EXAMPLE IF POSSIBLE.

This area opens some interesting lines of questioning which are beyond the full remit of this research

• Question - do more useful / less de-motivating errors result from remixing and game patching?
• Question - what impact does the process of being driven by GDPs have on how users deal with errors?
  • For example does the closely paired code structure and game output help with motivation?
  • How do you develop a more granular sense of the kinds of blocks, errors and how to overcome them.