Honours Individual Project Dissertation

LEARNING FROM SCRATCH

Lily Fleeting-Craig

August 20, 2026

Abstract

Web programming is considered an engaging entry point to learning to code, but it comes with

its own set of challenges that can push away novices. Block-based programming is a popular

solution to this problem, however no accessible system exists for young students. This project

investigated the usability of WebBlocks, a new simpliﬁed block-based editor for HTML and

CSS. It was found that participants reported signiﬁcantly higher perceptions of ease of web

programming after use of the system, though there is room for improvements to be made to

support usability for inexperienced users speciﬁcally.

Acknowledgements

I give my gratitude to my supervisor Fionnuala Johnson for her commitment to this project,

regularly bringing ideas and guidance throughout its duration, and for making it such an

enjoyable experience.

A huge thank you goes also to Una Marie Darragh, whose support throughout my degree has

made everything possible.

Contents

1 Introduction 1

1.1 Motivations 1

1.2 Aims 2

1.3 Summary 2

2 Background 3

2.1 Literature Review 3

2.1.1 Block-Based Programming 3

2.1.2 Abstraction and the Spiral Curriculum 4

2.2 Existing Editors 5

2.2.1 Supportive Features 5

2.2.2 Gap in Existing Solutions 7

2.3 Summary 7

3 Analysis 8

3.1 User Personas 8

3.2 User Stories 10

3.2.1 General 10

3.2.2 Language 11

3.2.3 Block-Based Editor 11

3.3 Requirements 12

3.3.1 General 12

3.3.2 Language 12

3.3.3 Block-Based Editor 13

3.3.4 Non-Functional Requirements 13

3.4 Summary 13

4 Design 14

4.1 Wireframes 14

4.1.1 Website Editor 14

4.1.2 Block-Based Programming Interface 14

4.1.3 Simple and Advanced Abstractions 16

4.1.4 Site Functionality 17

4.2 Summary 17

5 Implementation 18

5.1 Software Development Methods 18

5.1.1 Issue Tracking 18

iii

5.1.2 Git and Version Control 19

5.1.3 DevOps 19

5.2 Software Architecture 20

5.2.1 Blockly Library 20

5.2.2 Technologies 20

5.2.3 Architecture 21

5.3 Implementation Issues and Solutions 23

5.3.1 Simultaneous Resi zeable Blockly Workspaces 23

5.3.2 Toolbox Category Icons 23

5.3.3 Scoping 23

5.3.4 Debouncing Updates 24

5.3.5 Saving Content 24

5.3.6 Summary 24

6 Evaluation 25

6.1 Methodology 25

6.2 Participant Demographics and Background 25

6.3 Results 26

6.3.1 Task Results 26

6.3.2 Perceptions in Survey Responses 29

6.3.3 Pre-Survey and Post-Survey Changes in Attitudes 30

6.4 Summary 31

7 Conclusion 32

7.1 Summary 32

7.2 Reﬂection 32

7.3 Future work 32

A Additional Design Wireframes 34

B Additional Implementation Figures 36

C Evaluation 38

C.1 Experiment Questions 38

C.2 Ethics Checklist 44

C.3 Participant Brieﬁng and Consent Sheet 46

C.4 Additional Demographics Visualisations 49

C.5 Additional Results Visualisations 51

C.5.1 Task Results 51

C.5.2 Additional Survey Question Response Visualisations 52

C.5.3 Increase in Attitudes between Pre-Surveys and Post-Surveys 55

Bibliography 58

1 Introduction

In this chapter, motivations ar e described for a new programming environment for beginners to

web development languages. The aims for the development of the novel WebBlocks block-based

web programming system are subsequently deﬁned.

1.1 Motivations

Programming is perceived to be diﬃcult (Chen et al. (2019)) by those of all ages - particularly by

novices who become frustrated by syntax errors (Mladenović et al. (2018)). As a consequence,

dropout rates in the subject are high at all levels from primary-school into adulthood (Chen et al.

(2019), Mladenović et al. (2018), Kyfonidis et al. (2017), Sun et al. (2024), Weintrop and Wilensky

(2019), Sáez-López et al. (2016)). For these reasons, block-based programming languages have

been explored for decades (Begel (1996)) to oﬀer a low-friction introduction to programming to

engage learners and activate interest (Mladenović et al. (2018)). These allow users to combine

code structures together like puzzle pieces, avoiding the need to write or immediately understand

correct syntax. This enables novices to dive deeper into more nuanced concepts with less diﬃcult y

and without burdensome errors and debugging. For these reasons, systems like Scratch - shown

in Figure 1.1a - have grown immensely popular (Scratch Foundation (2026)).

Stepp et al. (2009) argues that web languages provide an eﬀective introduction to programming

as they facilitate creative practices and enable learners to build professional products with limited

time. Kim (2021) oﬀers that if students have rewarding experiences in this way, this makes

web programming a strong vehicle for motivating learners and improving self-eﬃcacy, possibly

allowing further development at a professional level. However, there are some diﬃculties almost

exclusive to development in these languages noted by Stepp et al. (2009) - unlike many languages,

HTML and CS S do not explicitly raise errors such a s in cases of misspelt tag names or missing

closing tags. This makes these mistakes diﬃcult to ﬁnd, which is compounded by a lack of

debugging tools and environments which are easily accessible for novices. A block-based editor

for this purpose could resolve many of these pain points that novices experience, but there exists

only one on the market - EduBlocks - shown in Figure 1.1b. It is recommended by Stepp

et al. (2009) that a graphical programming language is best used as a ﬁrst exposure to coding in

younger learners, particularly those aged 6-10, as these individuals see a statistically signiﬁcant

improvement in performance in later education than those who begin with a text-based language.

However, EduBlocks may not serve these younger learners a s well as a simpler language as its

syntax is still raw HTML, which may not be as easily understood (Soudani et al. (2024)).

Furthermore, Hermans (2020) suggests that presenting a simpliﬁed abstract syntax lowers the

barrier for entry for novices, eﬀectively separating learning area s of code structure and syntax.

This also allows learners to build sites without being held back by a lack of knowledge in some

areas, increasing their conﬁdence and enjoyment in the subject, and improves motivation. This

could then allow scaﬀolding of learning by gradually increasing complexity of the presentation

of language, either by bridging to text-based languages, or to a separate representation of blocks

in an abstraction closer to being more representative of the underlying HTML/CSS synt ax.

(a) Scratch (Scratch Foundation (2007)) (b) EduBlocks (Anaconda (2023))

Figure 1.1:

Interfaces of dierent block-based programming environment. (a) shows Scratch, a tool for

programming games suitable for those from young ages. (b) shows EduBlocks, a system for coding websites

by visualising raw HTML with blocks.

Therefore, a novel system could better serve learners in their approach to programming by

oﬀering a block-based programming editor for web pages at a syntax level appropriate for

younger students. This could then serve as the jumping point for a spiral approach to a computing

curriculum, where these concepts are covered at ﬁrst in this ba sic level, working upwards towards

the syntax of the underlying web languages like HTML and CSS (Statter and Armoni (2020)).

Further, the system could facilitate this by oﬀering high-level and low-level abstractions of this

syntax as ’advanced’ and ’beginner’ options, allowing users to move freely between the two.

1.2 Aims

The core purpose of this project is the creation of WebBlocks - a new block-based programming

environment for novices in web development languages. WebBlocks will oﬀer an abstraction

over raw HTML/CSS syntax using non-technical language to facilitate its use by younger and

more novice developers as an entry point to coding. The system should deliver a positive usability

experience by leveraging key design heuristics that are identiﬁed as being either demonstrated

by or absent from existing systems.

An overview of these aims is given below;

Investigation of relevant literature and current block-based programming environments,

their suitability for young and novice learners, and their usability in line with relevant

frameworks. (Chapter 2)

Analysis of requirements of the WebBlocks application in line with the ﬁndings in Chapter

2. (Chapter 3)

Design solution for WebBlocks in fulﬁllment of relevant needs and requirements identiﬁed

above. (Chapter 4)

4. Implementation of the WebBlocks system. (Chapter 5)

5. Evaluation of usability and preferability of the WebBlocks application. (Chapter 5)

1.3 Summary

In this chapter, the context was explored of the motivations for block-based programming

environments, and the challenges that exist for novices to web programming languages. A need

was identiﬁed for a new beginner-friendly block-based programming environment for web

languages. Lastly, the aims for the development of this project were outlined.

2 Background

In this chapter, concepts and literature in key problem areas of block-based programming and

abstraction levels in scaﬀolded learning are reviewed, and several existing and similar block-based

programming environments are presented. The usability of these systems is then contrasted

and compared with respect to a design framework, and key heuristics and features to contribute

to a positive and accessible experience are outlined. Lastly, a product gap in these solutions is

proposed.

2.1 Literature Review

2.1.1 Block-Based Programming

Block-based programming languages oﬀer graphical representations of code as blocks, which

users can connect together like pieces of a puzzle (Weintrop and Wilensky (2019)). This creates

a strong and simple metaphor which supports learners’ conceptualisations of permitted syntax

through combining elements using drag-and-drop mechanics with clear visual signiﬁers like

matching shapes (Weintrop et al. (2018)). An advantage of this modality over traditional text-

based programming languages is that it can entirely prevent combinations of blocks which

do not conform to valid syntax, thus preventing an array of errors which cause frustration for

novices (Weintrop and Wilensky (2018)). This reduces friction for new learners, and supports

project-based learning with reduced debugging.

Block-based programming is not a novel ideal, and has seen wide proliferation across a range of

target demographics and domains since the ﬁrst such language - Logo Blocks - was created by

Begel (1996). This ranges from app development with MIT App Inventor by the Massachusetts

Institute of Technology (2010), to the programming education initiative ’Hour of Code’ by

Code.org (2026) which has now seen 2 billion hours of use by those across every country in the

world (Weintrop and Wilensky (2019)). Most notably, it is argued by Weintrop (2019) that the

paradigm was popularised with great success by Scratch - created by the Scratch Foundation

(2007) - due to its simple block-based language requiring little formal educational support or

instruction. This has now enabled 135 million registered users of all ages to create video games

on the platform (Scratch Foundation (2026)).

Recommendations by Chen et al. (2019) suggest that block-based programming langu ages are

most eﬀectively introduced to learners in early ages of 6-10, resulting in a statistically signiﬁcant

improvement in performance in later education over peers who studied in a text-based modality.

In an experiment in an elementary school in Croatia, Mladenović et al. (2018) did not ﬁnd

signiﬁcant diﬀerences in performance between students in a text-based programming modality

and a block-based programming one using Scratch. However, researchers did conclude from

a lack of association between programming ability and test performance in the block-based

programming group that the Scratch system had a lower barrier to entry for novices. In a similar

experiment in a US secondary school, Weintrop and Wilensky (2018) found that a block-based

programming class performed signiﬁcantly better than a text-based programming class after

5 weeks of study. However, in a continuation of the same experimentation by Weintrop and

Wilensky (2019), it was observed that after a further 5 weeks of study, these modalities converged

and there was no signiﬁcant diﬀerence in performance between the two. Later research by Sun

et al. (2024) in a Chinese high-school class found similarly to Weintrop and Wilensky (2018)

that after 6 weeks of study, 13 year old students taught in a block based programming modality

performed signiﬁcantly better than a text-based one. Other research by Weintrop et al. (2018)

investigated the use of a block-based programming tool used to control a robot situated in the

context of professional use by novice users in an engineering company. Results showed that task

completion times in various activities were signiﬁcantly reduced under the block condition over

industry alternatives, which indicates that these tools have a lower barrier to entry.

Taken together these ﬁndings indicate that, in the worst case, block-based programming may be

used across demographics in the early stages of learning without detriment to future performance;

optimistically, some posit that use of block-based programming tools in early education are

associated with improved initial and later coding performance. This allows them to facilitate an

enjoyable initial exposure to coding to build motivation and encourage persistence, by reducing

friction and preventing errors, without detriment to ability.

2.1.2 Abstraction and the Spiral Curriculum

Statter and Armoni (2020) reﬂects that abstraction is at the core of programming, as a key skill

involved is being able to conceptualise the same problem in higher and lower levels. Bruner

(1966) proposed that knowledge is formed in three stages of learning;

Enactive representations are formed through physical experiences, like combining two

piles of objects together to teach addition. This is sometimes described as ’learning by

doing’ (Rannikmäe et al. (2025)).

Iconic representations are mental images made by perceiving and manipulating pictures -

for example, learning addition at the level of an iconic representation could be counting on

a number line with steps between two numbers.

Symbolic representations refer to abstractions of underlying concepts, in the way that the

equation

𝑎 + 𝑏

represents addition. Learning in this stage involves manipulating and using

symbolic representations like equations.

Armoni et al. (2015) notes that a block based-programming tool like Scratch uses all of these

three representations - these can be seen in the following aspects;

Enactive: Manoeuvring and manipulating blocks as a tactile act to join them together

represents the combination of code elements, structures and statements.

Iconic: Code is visualised graphically showing the nesting of statements, highlighted by

colour and shape.

Symbolic: The act of learning through abstraction, by understanding that individual blocks

such as comparison operators represent underlying programming concepts like logic.

Statter and Armoni (2020) remark that under Piaget’s traditional theories of cognitive develop-

ment, a key challenge with teaching younger children computing science is that they are not yet

at a stage of development where abstraction is possible. However, they claim that Bruner (1960)

sets out an alternative philosophy which oﬀers more hope. Bruner proposes a spiral curriculum,

whereby diﬃcult concepts are best taught repeatedly at diﬀerent levels of education in increasing

levels of complexity, starting from young ages. Importantly, Bruner suggests that any topic

can be taught to children, provided it is taught at a level appropriate for that age. Because of

their facilitation of understanding across the three stages of learning, simple block-based pro-

gramming tools like Scratch may be an eﬀective ﬁrst exposure to coding, using strong physical

metaphors to support enactive learning, and building up to a solid symbolic understanding of

core programming concepts. These ideas can then be revisited in a more technical block-based

abstraction, and later in a text-based modality as is appropriate for the age of the learner.

2.2 Existing Editors

One existing product on the market, EduBlocks (An aconda (2023)), was identiﬁed as making use

of the block-based programming paradigm for coding websites. It oﬀers the ability to code in a

variety of diﬀerent programming languages in either a text-based or block-based modality, but

does not allow transfer between them. In its block-based editor for HTML, diﬀerent elements

are provided in drawers in a toolbox categorised by the type of the element, such as ’Lists’,

’Text’, or ’Structure’. Users can also write CSS style rules using an internal CSS tag. One panel

contains the block-based programming editor where users can utilise drag-and-drop mechanics

to build code; the other allows users to toggle between live previews of either the rendered

page or its HTML and CSS code. Blocks are presented in a low-level abstraction, close to the

underlying HTML, including angle brackets and closing t ags. BlocklyHTML by Github user

ED-Info (2023), however, is a basic prototype of a similar system in a high-level abstraction using

plain-English language. BlocklyHTML also supports inline CSS as attributes applied to blocks.

Several block-based environments for other programming languages were also found. Noted

by Zeevaarders and Aivaloglou (2021) to be one of the most widespread beginner coding

environments, Scratch from S cratch Foundation (2007) allows novice programmers to create

video games using simple high-level plain-English blocks. In a bid to enable teaching of more

advanced concepts, Snap! was l ater developed by the University of California, Berkeley (2010) as

an extension of Scratch (Harvey et al. (2025)), also making use of an easy to underst and high-level

plain-English language set. App Inventor by the Massachusetts Institute of Technology (2010)

provides a UI design interface for users to create smartphone apps, for which users can implement

functionality by programming using blocks. The syntax of the code is abstracted from typical

underlying languages, but not quite as simpliﬁed a s other examples above. One bidirectional

editor - MakeCode by Microsoft (2016) - was found which allowed users to move between

high-level and low-level representations. Users can program real Python code in a text-based

editor to control a BBC micro:bit digital device (Kalogiannakis et al. (2021)), or edit this same

code in a high-level simpliﬁed view of the syntax in a block-based environment. The highly

successful Blockly library from Google (2012) was also identiﬁed a s a core component of many of

these applications, handling the block interactions and compiling of code in Scratch, MakeCode,

BlocklyHTML, and App Inventor, as well as providing useful functionality including warnings

and custom block deﬁnitions.

Finally, the frame-based structured editor Strype by King’s College London (2022) was also

noted, which allows users to code by building diﬀerent statements (e.g. if, while) using single

key presses, mitigating basic syntax mistakes, and errors in code structure by limiting user choice

for statements to only those valid in the given context.

2.2.1 Supportive Features

The 10 Usability Heuristics for User Interface Design framework by Nielsen (1994) was then

used to compare the usability of these systems, and establish common or missing features which

would enable learning and ease of use.

Identifying Misconﬁgured States (1: Visibility of System Status)

EduBlocks and Block-

lyHTML both make the state of the code clearly visible through the use of the live preview.

However, it is not clear whether the code is correctly conﬁgured according to best practices - for

example, two seperate <html> tags can be added in either editor, but there is no visual indication

of this mistake.

Categorisation of Elements and Best Practices (2: Match Between the System and the

Real World)

All of the block-based editors investigated categorise diﬀerent block types in

drawers in a toolbox, with category names which clearly align with diﬀerent taught programming

concepts, such as ’Variables’ and ’Control’ in Snap!, and ’Logic’ and ’Maths’ in App Inventor. An

Figure 2.1:

EduBlocks’ categorisation of elements in the toolbox with colours and icons (Anaconda (2023)).

example of this in EduBlocks’ toolbox is given in Figure 2.1. This creates a strong match between

these systems and the real world, and empowers a learner’s famili arity with these concepts.

Another point is that existing block-based HTML editors like BlocklyHTML and EduBlocks

create good representations of real inline and internal CSS respectively, but do not necessarily

reﬂect the typical best practices of external CSS sheets.

Undo and Redo Support (3: User Control and Freedom)

Strype, Snap!, and MakeCode

are examples of providing user control and freedom by allowing fast undo and redo actions

with clearly marked buttons in the editor interface as well as keyboard shortcuts - in a learning

environment particularly this provides the foundations for users’ experiments with the language

and its output. EduBlocks, Scratch, and MIT App Inventor support these keybinds, but do

not provide buttons for this functionality explicitly in their interfaces, which may create issues

particularly for novice users who might not have previous experience with these shortcuts in

IDEs or word processors.

Compilation of Invalid Code (5: Error Prevention)

All block-based editors identiﬁed enforce

correct implementation of parent hierarchies inherently as a mechanic of the paradigm. This

supports valid syntax through removing responsibility over this from user, and prevents many

common beginner errors supporting initial discovery of the language. However, more could

be done to prevent mistakes in the typical structure of web code that don’t necessarily throw

errors. EduBlocks allows, for example, nested duplicated <style> or <head> tags which - while

these mistakes are technically not enforced by the language - do not support learners’ mental

constructions of correct use of the language.

Use of Colour and Iconography (6: Recognition over Recall)

In addition to the categorisa-

tion of elements supporting a user’s understanding of real-world coding concepts, colour is used

in all these block-based environments to produce distinct visual relationships between elements

within each category, and ultimately reduce the cognitive load of users’ by allowing users to

recognise where a given element is found rather than looking for it explicitly. Further, EduBlocks

and MakeCode both make use of symbols in the drawers of their block toolboxes to establish these

clear relationships. For example, in the MakeCode interface an icon of headphones accompanies

the ’Music’ label, and in the EduBlocks interface a movie-reel icon is featured with ’Media’.

Combinations of Blocks (7: Flexibility and Eﬃciency of Use)

BlocklyHTML provides a

unique feature amongst these implementations - in the toolbox, it combines some typical selections

of blocks to provide accelerators to users for building, as well as providing concrete examples of

best practices of coding. For example, it gives a shortcut to the implement ation of the structure

of a new page as seen in Figure 2.2.

Restricting Choices (8: Aesthetic and Minimalist Design)

EduBlocks and BlocklyHTML

minimise the visual clutter of the range of elements by organising them in the toolbox; however,

Figure 2.2:

Combined blocks toolbox option for new page structure in BlocklyHTML (ED-Info (2023)).

users are still presented a vast number of blocks that may not be necessary in a given context.

For example, if a user hasn’t added an <html> tag then options for <head> and <body> would

not need to appear. In Strype, the editor only permits options to add valid statements in a given

context - this reduces the selection visible to the user to present a minimalist design and aid

choice, eﬀectively imposing guardrails.

Snap! and MIT App Inventor do not show a minimal design in general - both interfaces contain

visual clutter which reduces their usability, particularly for novice users who might become more

overwhelmed.

Warnings and Errors (9: Help Users Recognize, Diagnose, and Recover from Errors)

MIT App Inventor displays errors and warnings clearly with descriptions of the actions necessary

to recover from them. These support the ability of learners to eﬀectively debug their code with

little supervision.

Tooltips (10: Help and Documentation)

None of the tools identiﬁed provided strong help

and documentation of blocks, their purpose, or their syntax. MIT App Inventor allows for the

modiﬁcation of some blocks, which indirectly gives information on parameters and return types,

which supports this heuristic to some extent, but this is not immediately obvious to someone

with little experience.

2.2.2 Gap in Existing S olutions

A novel system could be proposed which oﬀers block-based programming for web languages in

a high-level plain-English abstraction to be more suitable more younger children. This could

leverage the usability heuristics outlined above to provide novice programmers a simpler and

more enjoyable ﬁrst exposure to coding websites. Additionally, it could help learners internalise

a strong foundation of the separation of concerns between HTML and CSS by presenting these

in separate environments, which no product currently oﬀers. This system could also be further

extended to provide multiple abstraction layers over the syntax at diﬀerent levels of technicality

to enable later development in a spiral curriculum approach.

2.3 Summary

An overview was provided of relevant literature covering key concepts of block-based program-

ming and it’s use in varying demographics, as well as abstraction and the spiral curriculum. Some

existing block-based programming environments, including one editor for web languages, are

discussed and evaluated in relation to a usability framework. C ore features to support learning

and general use are then identiﬁed.

3 Analysis

This chapter presents the elicitation and prioritisation of both functional and non-functional

software requirements. Personas representing the typical users of the system were produced,

which were then used to derive expected use cases in the form of user stories. F rom these, sets

of both functional and non-functional requirements were then created, and assigned a priority

through the MoSCoW process. This deﬁned the core minimum viable product for the system in

line with its time limitations for production.

3.1 User Personas

In total, three personas were designed to deﬁne an impression of the scope of typical users of the

system, including both students developing and learning in the IDE, and educators assigning

tasks and teaching.

The needs and characteristics of learners who may use the system vary greatly, so two personas

provided endpoints across various spectra of attributes of the broader group, shown in Figures

3.1 and 3.2. A system designed to facilitate a positive experience for both endpoints would be best

considerate of the disparate requirements of those between, while maintaining a balance for the

limited resources and scope of development of the project. One key trait included was the level

of experience of the learner – a younger student without previous experience in programming

creates a demand for simpliﬁed concepts and more abstracted material, as well as a focus on the

material production of the website itself, whereas a more advanced teenage student balances this

with a need for accelerators like fast undo and redo actions, and desires to experiment and view

code in an abstraction close to raw HTML to develop an accurate understanding of its syntax and

relationships within the DOM. These personas also demonstrate diﬀerences in the origin of the

motivations of each learner, between more intrinsic drives of advancing understanding of coding

skills and more extrinsic ones to produce a well received piece of work through coding as a

creative outlet. Additionally, the environment of the learner varies between a self-taught student

working at home with limited access to formal educational resources and teaching or supervision,

who requires guardrails in pl ace for debugging and prevention of mistakes in syntax to facilitate

independent study, and a school pupil who may have more support from knowledgeable teachers,

but less consistent access to digital resources, such a s using a diﬀerent computer each time they

access the system.

Figure 3.3 shows a further persona developed to illustrate the use ca ses of the system by teachers

in an educational capacity. This includes features of management of the workspace, such as

importing and exporting code, and organisation of students. Particularly though, this brings a

motivation to represent the same code in diﬀerent layers of abstraction in order to employ a spiral

curriculum approach in teaching, and move freely between these high and low levels during

development.

Figure 3.1:

Persona of older advanced home learner with higher technical ability and higher intrinsic

motivation.

Figure 3.2:

Persona of younger novice school student with lower technical ability and higher extrinsic

motivation.

Figure 3.3:

Persona of a school teacher who aims to use a block-based programming environment in a

classroom to teach web programming, and assign and manage work.

3.2 User Stories

User stories were then created and arranged according to their corresponding area of functionality.

As in the personas described above, the user type in each story is either a teacher or a learner

- or sometimes speciﬁcally school students or home learners, novice or advanced learners, and

creatively-focused or skills-focused learners.

3.2.1 General

•

As a teacher, I want to organise students into cla sses so that I can organise their work and

monitor its progress, ensuring that it is appropriate.

•

As a teacher, I want to distribute starting code to students so that they can complete tasks.

•

As a teacher, I want to receive code from students without losing formatting so that I can

mark it.

• As a learner, I want to publish my website to share it with cl assmates and my family.

•

As a learner, I want to view the version history of my work so that I can understand my

progress over time.

•

As a learner, I want to duplicate a previous project to use a s a starting point so that I can

experiment freely without overwriting work I want to keep.

•

As a school student, I want to access my school work from a home computer so that I can

complete homework exercises.

•

As a school student, I want to drag and drop blocks with touch input so that the editor

works on the tablet provided by the school.

•

As a home learner, I want the editor to continue to function on a poor connection so that

my work isn’t disrupted by network latency issues.

• As a novice learner, I want to keep my work private so that other people can’t see it.

•

As an advanced learner, I want to export my project as a zip of HTML/CSS ﬁles so that I

can continue working on it in a local editor.

3.2.2 Language

•

As a teacher, I want to switch between levels of abstraction in the representation of the

block code to scaﬀold lessons that teach diﬃcult concepts.

•

As a novice learner, I want the option of coding in a high level plain-English abstraction so

that I can build sites and understand the value of web-development without being held

back by diﬃculties with syntax and terminology.

•

As an advanced learner, I want the option of coding in blocks in a low level technical

abstraction so I can understand real HTML/CSS syntax.

•

As an advanced learner, I want to code interactivity into the website so that I can learn

further concepts like JavaScript.

•

As a skills-focused learner, I want to code the structure of the website so that I can learn

the hierarchy of HTML.

•

As a creatively-focused learner, I want to style the website with colours and fonts so that I

can enjoy the design process of web development.

3.2.3 Block-Based Editor

•

As a learner, I want to see the real output of my code as a website so that I can see my

progress without downloading and running it.

•

As a learner, I want the website preview to update quickly so that I can receive quick

feedback to understand the relationships between elements when I move them.

•

As a learner, I want to see the HTML output of my blocks so that I can see how they

translate to real code.

•

As a learner, I want to resize my webpage output window so that I can see how my content

scales.

•

As a learner, I want to see a description of a block when hovering over it to understand its

meaning and syntax.

•

As a home learner, I want the editor to warn me of errors to help me debug errors without

supervision.

•

As a home learner, I want to highlight an element in the preview when I interact with its

block so that I can quickly grasp the meaning of elements without help.

•

As a novice learner, I want the code editor to prevent basic syntax mistakes so that I can

continue to create when I don’t yet fully understand correct syntax.

•

As a novice learner, I want the code editor to notify me of missing attributes from elements

so that I can understand proper syntax.

•

As a novice learner, I want the code editor to prevent nesting of incompatible element

types so that I can learn correct page structure.

•

As a novice learner, I want to use pre-combined selections of blocks (e.g. lists with list

items) to make development faster and easier.

•

As a novice learner, I want to use diﬀerent types of elements organised by colour and

iconography to understand relationships between them.

•

As an advanced learner, I want to use undo/redo buttons to speed up my experimentation

with web languages.

•

As an advanced learner, I want to apply style rules to elements using class and id attributes

so that I can learn granular styling.

3.3 Requirements

During the process of requirements elicitation, user stories from Chapter 3.2 were reﬁned into sets

of both non-functional requirements and functional requirements, arranged by the same previous

corresponding system areas. These were then assigned one of four priority levels through the

MoSCoW method (Kravchenko et al. (2022), International Institute of Business Analysis (2015));

•

M (Must have): The core feature set necessary for successful project completion in some

form.

•

S (Should have): Key requirements that ought to be included, but are not necessary for

delivery of the MVP.

•

C (Could have): Requirements that would be favourable for inclusion, but ultimately are

not necessary.

•

W (Won’t have): Requirements of this project iteration which have been speciﬁcally

omitted.

Note that the requirement number following each priority does not indicate a higher importance

than any other requirement under the same label, as these are ﬂ at categories (Hudaib et al. (2018),

Consortium (2026)). This triaging process is performed as delivery of all requirements would

lead to a probable breach of project limitations (Kravchenko et al. (2022)) - in particular, the key

restraint for this project was time, a s all areas ere staged to be completed within two months.

The essential feature set under the ’Must have’ category represents the minimum viable product

(MVP). Due to the mentioned time constraints, this was deﬁned to be a concept local block-based

programming Integrated Development Environment (IDE) for HTML written in a high-level

language, accessible for younger and novice learners, as aligned with the discovered gap in

existing solutions in Chapter 2.2.2. Allocation of ’Must haves’ is approximately 20% due to the

considerable time constraints of the project - signiﬁcantly below the 60% project eﬀort maximum

as per recommendations (Consortium (2026)). Similarly, ’Could haves’ constitute 25%, around

the 20% guideline.

3.3.1 General

S1: The system shall allow projects and sites to be accessed across devices using user accounts.

S2: The system shall allow users to publicise a view of their project to be shared as a webpage.

C1: The system shall allow users to duplicate and delete projects.

C2: The system shall allow users to have ﬁne-grained control of who can view their projects and

sites.

C3: The system shall allow users to view document version history.

W1: The system shall allow teacher users to manage ’classes’ of student users.

3.3.2 Language

M1: The system shall allow users to edit the web page’s structure using HTML.

M2: The system shall allow users to program in a high-level plain-English abstraction.

S3: The system shall allow users to edit the web page’s styling using CSS.

S4: The system shall allow users to program in a low-level code-like abstraction.

S5: The system shall allow users to toggle between abstraction layers.

C4: The system shall allow users to apply style rules to elements using class and id attributes.

W2: The system shall allow users to edit page interactivity using JS.

3.3.3 Block-Based Editor

M3: The editor shall prevent users from making mistakes in the DOM parent-child hierarchy.

M4: The editor shall allow users to view their block code as HTML/CSS/JS.

M5: The editor shall allow users to view a preview of their website.

S6: The editor shall give users warnings of errors in their code, such as missing attributes.

S7: The editor shall allow users to undo and redo actions.

S8: The editor shall allow users to ﬁnd categorically organised elements in the toolbox.

S9: The editor shall allow users to use pre-combined selections of elements in the toolbox.

S10: The editor shall give users hints on block meanings and syntax.

S11: The editor shall allow users to resize editor panels.

S12: The editor shall highlight an element in the preview on interaction with its corresponding

block.

C5: The editor shall allow users to export their work as block code.

C6: The editor shall allow users to export their work as web code.

W3: The editor shall allow users to upload block code to edit it.

3.3.4 Non-Functional Requirements

M6: The system shall update the page preview rapidly when the block code is changed.

M7: The system shall support projects containing enough blocks to build a basic website without

degradation of editor responsiveness.

S13: The system shall automatically recover the latest saved version of a project after an unexpected

browser or application closure.

S14: The system shall allow changes to be made to project code and corresponding preview

without an active internet connection.

S15: The system shall require authentication before allowing access to private projects.

C7: The system shall synchronise oﬄine changes when an internet connection becomes available.

C8: The system shall allow interactions to be made by either touch or mouse-click.

3.4 Summary

User personas were deﬁned to illustrate the likely users of the system; these were learners - with

varying past experience, motivation, age, and environment - and teachers. User stories were then

created to identify the expected use cases of these personas, and further developed into functional

and non-functional requirements. These were ﬁnally triaged using MoSCoW prioritisation,

designating an MVP for the project to be a block-based programming editor appropriate for

younger and novice learners of web development languages.

4 Design

In this chapter, a design solution is proposed in line with the speciﬁcation identiﬁed in Chapter

3.3. Wireframes for each page of the site’s core functionality are presented and described with

reference to their fulﬁlment of each requirement, as well as relevant design principles under

Nielsen’s usability framework.

4.1 Wireframes

Core pages of the site were mocked in line with the positive design principles of existing systems

outlined in Chapter 2.2.1, as well as the underlying user interface design framework set out by

Nielsen (1994). High-ﬁdelity wireframes were produced to design a system in suﬃcient detail to

plan minute interactions in the editor. These wireframes are described below with reference to

the system requirements elicited in Chapter 3.3.

4.1.1 Website Editor

The editor contains two windows as seen in Figure 4.1, which can be resized dynamically (S11)

by dragging the divider in the middle of the panels. Both of these windows contain tabs at the

bottom of the panel clearly identifying diﬀerent options, using colour-coding and iconography

to assist the user in recognising these areas, supporting Heuristic 6 (Recognition over Recall).

On the left, these options are previews of either the website or its code. Figure 4.1 shows a live

preview of the rendered site in a simulated browser, allowing information like the site title to be

displayed (M5). In Figures 4.2 and 4.4, the computed code associated with the user’s blocks is

displayed under the respective ﬁlenames for the HTML and CSS ﬁles (M4). The toolbar shows

drop-down options to save code in either the block-based (C5) or text-based modalities (C6).

Additionally, users can access a menu to control who can access both their code and its deployed

site (C2) through the ’Who Can View’ toggle on this toolbar, discused in Site Functionality.

Bright colours and clear labels are featured throughout to present a visually attractive minimalist

interface - in line with Heuristic 8 (Aesthetic and Minimalist Design) - suitable for younger

learners. However this is balanced by maintaining a clean and modern UI with dark accents

mimicking professional I DEs, as research by Tran et al. (2026) suggests excessive use of bright

colour across the whole UI, and a maximalist aesthetic, demotivates older students by creating an

impression of childishness.

4.1.2 Block-Based Programming Interface

On the right side of the interface as seen in Figure 4.2, the user can access tabs for programming

the structure or style of the website (M1 and S3). The ﬁgures show how the block-based

programming modality inherently prevents mistakes in the parent-child hierarchy (M3), a s

blocks are placed inside others prohibiting misconﬁgured closing tags. Figure 4.2 shows blocks

separated from the page deﬁnition being automatically disabled and excluded from the compiled

code. A toolbox panel on the left presents elements users can drag to add to the window. These

are categorised by type to support user choice (S8) through Heuristic 8 (Aesthetic and Minimalist

Figure 4.1:

Wireframe showing an editor with high-level plain-language blocks coding the site structure

in an abstraction of HTML, beside a live preview of the website. The user is highlighting the header

element in the view using a preview button on the corresponding ’Biggest heading’ block.

Figure 4.2:

Wireframe showing an editor with low-level blocks coding site structure in HTML, and a

preview of the compiled code. The user is highlighting the <h1> tag by clicking a button on its block. Two

blocks orphaned outside the structure of the page are disabled, and a warning is displayed to the user.

Figure 4.3:

Wireframe showing an editor with plain-language blocks coding site style and a preview of

the compiled code - no CSS is present here as the user has only added non-valid blocks. A warning appears

on the block notifying the user that the style rule is not valid as it does not contain a selector.

Design). These relationships are established through clear use of colour, and accompanying

iconography. Figure 4.2 shows how blocks can be combined in the toolbox to build t ypical

code structures to present examples of best practices to new users (S9) and provide accelerators

under Heuristic 7. Figures 4.3 and 4.2 show how the editor can give warnings to users, such

as those of missing selectors in CSS style rules or elements separated from the page hierarchy

respectively (S6). Clearly visible buttons allow users to quickly undo and redo actions (S7)

pursuant to Heuristic 3 (User Control and Freedom). Figure 4.1 shows how some properties can

be visualised for users to support Heuristic 6 (Recognition Over Recall), such as by displaying the

various heading types in HTML in their display size with descriptive names, rather than using

more complicated concepts like <h1>, <h2>, etc. Additionally, Figure 4.1 shows that users can

click on any block in the editor to highlight its respective element in the website preview (S12).

4.1.3 Simple and Advanced Abstractions

Figures 4.1 and 4.3 show a presentation of blocks in a high-level plain-English langu age abstrac-

tion to code HTML and CSS respectively (M2). These remove explicit closing tags to simplify

code, and use clearly understandable terms to facilitate use by novices, such as ’Bullet point list’

rather than ’<ul></ul>’. This supports Heuristic 6, Recognition Rather than Recall, such as by

displaying a visualisation of heading sizes rather than ’heading 1’, ’heading 2’, etc. On the other

hand, ﬁgures 4.2 and 4.4 depict a low-level raw code abstraction, with verbose deﬁnitions of

HTML and CSS tag syntax including closing tags. This gives learners a better conceptualisation

of the real syntax of these elements. A toggle is given in the header’s toolbar to move freely

between these ’Simple’ and ’Advanced’ abstractions. When this toggle is clicked, it instantly

changes the syntax of all blocks in both the HTML and CSS editors to the required abstraction.

This would essentially change the view of the HTML editor, for example, from the panel in

Figure 4.4:

Wireframe showing an editor with low-level blocks coding site style using CSS beside a

preview of the compiled code.

Figure 4.1 to the one in Figure 4.2. A learner can use this to get clariﬁcation on the meanings of

low-level syntax by translating them to a simpler abstraction.

4.1.4 Site Functionality

A publish button on the editor toolbar allows users to ship their site, in line with the privacy

policies they have deﬁned (S2). These policies can be set in the ’Who Can View’ controls, allowing

young users to have granular control of others’ access to their data in a way they can understand.

This means including levels of access, such as ’Read’ and ’Edit’, with categories of users like

’Teachers’, ’Classmates’, and ’Others’. The rendered website can be seen demonstrated in Figure

A.2 - this appends a footer to take visitors to the main site, as well as providing options to code

their own project, or edit this one. This creates a strong compounding growth mechanism,

encouraging visitors to these published sites to join WebBlocks. Figure A.1 shows how users can

view and manage their sites, including creating new projects, and editing, deleting, or duplicating

current ones (S1).

4.2 Summary

A system was proposed in line with the requirements elicited in Chapter 3.3 and the design

principles exhibited in the existing products identiﬁed in Chapter 2.2.1. This demonstrates a

bi-directional IDE to facilitate development in both HTML and CSS at high-level plain-English,

and low-level raw-code abstraction layers. High-ﬁdelity wireframes were produced to outline

the core pages of the site and detailed interactions in the block-based editor. Lastly, these areas

were described in depth to document this design.

5 Implementation

In this chapter, the choices made during the course of the project are identiﬁed and described.

This includes the development methods used to minimise the time and eﬀort required for

implementation, as well as the architecture of the ﬁnal software product, and the problems

experienced over the course of its development.

5.1 Software Development Methods

Mature agile methods were used to streamline the software development process, which was

made particularly necessary due to the limited length of time allocated for the project. These

processes are outlined below;

5.1.1 Issue Tracking

A Trello (Atlassi an (2011)) issue board was used for high quality issue tracking. Five columns

were employed for a Scrum task ﬂow, where individu al tasks were added initially to a backlog,

selected for each sprint, and moved according to their activity. These columns were;

1. Backlog

2. Current sprint

3. Active

4. Blockers/Pending

5. Done

Each task was given an issue number which was then referenced in corresponding branch names

and commit messages. Story points were also assigned to each issue to provide estimates of eﬀort

to guide later sprint planning and task selection. The availability of a well deﬁned backlog was

identiﬁed early in the development process as necessary for maintaining high project velocit y,

as more issues could be eﬃciently pulled into a sprint on successful work completion. This is

demonstrated in Figure 5.1.

Figure 5.1:

Issue board in 5 columns (Backlog, Current Sprint, Active, Blockers/Pending, Done). Each

issue indicates number of story points, task type (Feat, Test, or Fix), and issue number (Atlassian (2011)).

5.1.2 Git and Version Control

Github was used for version control of code allowing for the rollback of mistakes introduced

into the codebase and monitoring of the progress of development over time using Git history, as

well as for the use of pipelines for assurance of high code quality.

Branching

Although feature branching wasn’t used due to the limited scope of development

and the lack of risk associated with incremental delivery for this particular project, branching

was used for pull requests according to the convention below to clearly identify progress in

pull requests, as well as supporting Git rollback functionality by allowing clear identiﬁcation of

branches;

users/lily/[task/fix/deploy]/[issuenumber]-description

Conventional Commits

The Conventional Commits (2019) .gitcommit template was used to

document progress in commit and pull request messages - this supported the ease of later

identiﬁcation of work completed for sprint reviews, as well as validation of successful task

completion in pull requests.

5.1.3 DevOps

Modern DevOps practices - described by Kim et al. (2016) - were employed to streamline the

continuous implementation, quality assurance, and deployment of builds. Two pipelines were

created in Github Actions, which are discussed below. This functionality was a key motivating

factor in the selection of Github as a version control system, as this is provided natively by Github

Actions in GitHub (2026a).

A continuous integration (CI) pipeline was deﬁned to maintain the quality of code published

to the repository, with the following stages;

Checkout repository: Inst all the most recent published code from the Github repository

using the standard actions/checkout@v4 action.

Setup Node.js: Install the newest version of the Node.js runtime environment using

the actions/setup-node@v4 action. This required the use of the deﬁnition of the cache-

dependency-path property for dependency installation.

3. Install dependencies: Download necessary dependencies including Blockly.

Check formatting: Check adherence of code to the style rules using the Prettier opinionated

code formatter created originally by James Long (2017).

5. Lint: Perform static code analysis using ESLint from the OpenJS Foundation (2026).

6. Type check: Validate TypeScript typing.

Test with coverage: Run Vitest tests from VoidZero Inc. (2026) with minimum test coverage

requirements where necessary. Note that these thresholds were omitted due to limited

development time deprioritising this aspect.

8. Build: Run Vite preview to ensure successful build.

The success of this pipeline was required on pull requests to ensure that many mistakes could

be caught without manual validation, reducing time both in reviewing code, but also in ﬁxing

future issues, as well as maintaining code quality throughout development.

Deployment

Another core reason for using Github is the availability of Github Pages. This

allows for the publishing of static sites on servers provided by Github (2026b). This was made

easily possible as no backend was implemented for the project, and the site was coded in pure

TypeScript/JavaScript/HTML/CSS. This was automated with Github Actions, so that new

successful releases would immediately be available in a live deployment, through the following

stages;

Checkout repository: Inst all the most recent published code from the Github repository

using the standard actions/checkout@v4 action.

Setup Node.js: Install the newest version of the Node.js runtime environment using

the actions/setup-node@v4 action. This required the use of the deﬁnition of the cache-

dependency-path property for dependency installation.

3. Install dependencies: Download necessary dependencies including Blockly.

4. Build: Build TypeScript code.

5. Setup pages: Setup Github Pages using actions/conﬁgure-pages@v6.

6. Upload artifact: Upload compiled code distribution.

7. Deploy to GitHub Pages: Deploy using actions/deploy-pages@v5.

This pipeline is called on successful push to main, and therefore only after the validation pipeline

has passed.

5.2 Software Architecture

5.2.1 Blockly Library

Early on in the development process, the Blockly library from Google (2012) was identiﬁed as

a core dependency. This contains behaviour for block interactions, as well as scaﬀolding for

functionality which would otherwise require an amount of time which was unavailable due to

project constraints. An overview of the typical components of a Blockly app (Blockly (2026a)) is

provided below;

• blocks/: Block deﬁnitions can be added here in either JavaScript or JSON.

•

generators/: The translations of blocks are given here for each deﬁnition, to allow code to

be serialised correctly.

•

serialization: Functionality for serialising the compiled code from the block editor and

saving it to local storage are given here.

• toolbox: The structure of the toolbox side panel is deﬁned here.

• workspace: The Blockly workspace is deﬁned and injected here with its toolbox.

5.2.2 Technologies

A lot of deliberation was made over the stack of frameworks and languages used. The most

important functionality of the site was its block-based programming environment. The infras-

tructure which would allow persistent online storage of user accounts, projects, and sites, as well

as dynamic content presentation and routing for these elements, was desirable but not strictly

necessary in order to deliver the MVP as deﬁned by the must-have requirements in Chapter

3.3. Due to the limited development timeline, a risk to the successful delivery of the editor

was reducing the velocity of the initial project setup through the conﬁguration of an unused

backend and database that would ultimately introduce deployment challenges without adding

f unctionality. Therefore, the biggest consideration was that it was essential that each system

component should be deliverable separately, a s the limited development timeline left it unclear

whether each additional component would be completed. Another wider issue was that each

technology had to be readily and easily compatible with Blockly without signiﬁcant integration

diﬃculties.

TypeScript was deemed to be helpful to catch syntax errors that might otherwise go unnoticed,

at the minor cost of a slight learning curve. This reduces total eﬀorts by minimising debugging

which would harm project velocity.

React seems at ﬁrst glance to be a strong choice for a frontend framework due to allowing the

quick and seamless inclusion of open source components. However, React’s virtual DOM which

controls the structure of the page would create integration issues with Blockly, as the library

relies on direct DOM manipulation by injecting a Blockly instance into the tree structure of

the site. Note that this issue also exists in full-stack approaches like SvelteKit or Next.js which

perform server-side rendering (SSR), and therefore do not have a DOM. Additionally, these

components would not support the editor itself but rather other UI elements further down the

line, so the framework is not immediately useful for the delivery of the MVP.

It was decided then that the most eﬃcient strategy to create a working prototype would be

avoiding a frontend framework entirely. Pure TypeScript or JavaScript keeps the codebase simple,

and the block-based editor functionality - which constitutes the core MVP - would be written

in these languages anyway. Vite could be used eﬀectively to package and bundle the app, run

various test and linting tools, as well serve the code on a development environment. Vue.js could

then be easily added in an incremental approach, as it requires minimal change to pipelines and

other infrastructure - this would allow a more mature codebase for other site pages with a greater

separation of concerns.

It was decided that Express was the most appropriate backend due to its lightweight and decoupled

nature, which would allow it to be easily added after the completed creation of the frontend, by

serving this from a separate folder. However, TypeScript support would need to be conﬁgured

manually which is a minor barrier. Databasing could be added simply with Prisma and Post-

greSQL. The popular modern backend framework Nest.js would natively support TypeScript, but

was rejected due to the reconﬁguration of project structure that would be required when adding

it to an existing frontend, which would create additional overhead by breaking pipelines. This

would essentially mean having two separate setup phases, which would be undesirable given the

time constraints of the project, worsened by unfamiliarity with the frameworks. Another option

for a backend would be Django for Python - the main advantage of this would be a f ast velocity

with a full-stack initial approach for project setup due to existing familiarity with the framework,

as well as immediately supporting authorisation and routing with slugs. However, as discussed

above, the initial setup cost of the framework may prove worthless if backend functionality

and storage is eventually omitted, and late integration of Django could pose its own diﬃculties.

Additionally, Django would require more eﬀort to conﬁgure initial automated deployments than

would otherwise be the case for a lightweight frontend-ﬁrst approach.

In summary, an initial editor prototype could be quickly built with Typescript to support explicit

typing for error prevention, and developed and bundled using tools to support maintainability

like Vitest, Prettier, and ESLint with Vite. Vue could then be used for the frontend development

of other site pages to ensure readability and maintainability of the codebase. An Express backend,

alongside Prisma plus PostreSQL for databasing, could later be added with minimal disruption.

5.2.3 Architecture

Figure 5.2 provides an overview of the composition and architecture of the block-based pro-

gramming editor. The core components can be seen in line with the structure of a Blockly app

described above in Chapter 5.2.1. The editor includes functionality for dynamic control of the

IDE interface including controls to toggle between tabs (Web Preview and Code Preview, and

Style and Structure), as well as resize the Blockly workspace instances dyn amically according to

the siz e of the screen, and the ratio between the left and right screen panels. Further detail is

given below on the implementation of these components.

Workspaces and Toolboxes

Two workspaces are deﬁned and injected into the tabs for pro-

gramming the HTML and CSS of the website, with references to their respective toolboxes which

display available blocks in the sidebar. They also implement a custom theme which is responsible

for the styling of the categories in their toolboxes. The type of each of these workspaces is

Figure 5.2: High level overview of the architecture of the WebBlocks block-based programming editor.

then extended to include their workspace type (HTML or CSS), and then they are both stored

associatively in a mapping against their workspace type.

Generators

Due to requirements for scoping the user’s CSS style rules to the preview window,

as described below, two generators are deﬁned for the website preview and the code preview.

The architecture of this is shown in Figure 5.3.

The code preview generator compiles the block-based code as the user has written it into its

underlying HTML and CSS languages. This is presented as two separate ﬁles as seen in Figure

B.2. In order to apply these style rules, it is necessary for the user to add a ’Stylesheet’ block

as they would normally include an external CSS ﬁle in the <head> of their HTML ﬁle - this is

demonstrated in Figure B.4. If no stylesheet is included, a warning of such is displayed above any

style rules the user has created in the CSS tab, shown in Figure B.3.

The website preview generator instead includes the style rules as internal CSS in a <style> tag,

and scopes them so that they only apply within the preview window so that the design of other

parts of the IDE is not aﬀected.

Each of these preview generators requires two low-level generators to translate the blocks in

both the CSS and HTML tabs into their underlying syntax.

Blocks

In Figure B.5, it can be seen that blocks are deﬁned according to their category in the

toolbox for both the HTML and CSS languages under their presentation in a plain-English

abstraction. Note that each HTML element deﬁned requires its selector to be designed separately

in the CSS blocks speciﬁcation.

Figure 5.3:

Diagram of the composition of high-level and low-level generators for the compilation of

website or code previews, and underlying block syntax respectively.

5.3 Implementation Issues and Solutions

5.3.1 Simultaneous Resizeable Blockly Workspaces

Fraser (2015) added functionality to Blockly to allow the injection of multiple Blockly workspaces.

HTML and CS S workspaces were deﬁned separately, and stored against their type (HTML or

CSS) in a mapping. However, the ﬁrst encountered problem was allowing these two workspaces

to be dynamically resizeable. Following guidance from Blockly (2026 b), two workspace area

<div> elements were deﬁned in the structure of the page, and the workspaces themselves were

injected separately. By resizing each <div> element with respect to other as a fraction of the

screen width on every resize event, the Blockly instances tracking each are dynamically changed.

This can be seen in Figure

. To maintain these sizes between page accesses on the same device,

the ration of the panels was saved to local storage and loaded at start time. This was deemed

necessary as a bug initially existed which would freeze the toolbox when changing tabs between

the HTML and CSS editors, requiring frequent refreshes, though this was later ﬁxed.

5.3.2 Toolbox Category Icons

A key challenge faced was implementing icons to provide visual signiﬁers for categories in the

block toolbox. Blockly is injected at runtime, so it is not possible to redeﬁne the toolbox structure

explicitly to contain icons. Blockly also does not provide functionality to support adding multiple

icons - however, one icon can be added to all or some categories as each contains a sprite which

can be changed, and enabled or disabled seperately. This is described in a code-lab provided

by Blockly (n.d.). A workaround was used which injects the icons directly into the category

drawers after Blockly loads in the browser on the event DOMContentLoaded by ﬁnding each

instance of the class blocklyToolboxCategoryIcon. This is poor practice, as it relies on this exact

convention being maintained in the Blockly library, however no alternative could be found

outside of waiting for the extension of this feature to Blockly oﬃcially or using a custom branch

of Blockly which supports this. These icons can be seen in the toolbox in Figure 5.4.

5.3.3 Scoping

Since the CSS editor allows users to create style rules for the page which are applied dynamically,

another problem was that these would not be limited exclusively to the preview window. This

would result in style issues such as background colours behind links on the wider interface. To

Figure 5.4:

Implemented block-based programming interface with resizeable panel widths, displaying

a preview of the rendered website, and code for the structure of the site in a simpliﬁed language, with a

colour-coded toolbox with category icons.

ﬁx this, the CSS code had to be generated diﬀerently for the site preview - which should be

scoped to the window - and the code preview - which should show as the user has written it.

This motivated the separate generators described in the architecture above.

5.3.4 Debouncing Updates

In order to prevent ﬂickering in the event of quick successions of changes made to the code by

the user, each refresh of the code and site previews were debounced to a minimum buﬀer period.

This reduced visual lag at high numbers of blocks in order to maintain fast performance.

5.3.5 Saving Content

As the editor exists only in the browser, it is not possible for a user to view their code between

visits on diﬀerent devices. Therefore, the block code is saved to local storage in the browser, so

that the user’s project can be accessed again on the same device in subsequent visits. The same

is true for the user’s conﬁguration of their environment, so that their active preview and code

language tabs, a s well as the ratio of these panels, remains consistent. Further development could

see the inclusion of a backend with user accounts and authentication, storing and serving this

information instead from a database.

5.3.6 Summary

Choices of mature professional software development methods were explained to minimise

eﬀort in development and operations. A stack of technologies was selected with TypeScript and

JavaScript for the initial editor prototype, bundled, tested, and ran in a development environment

using Vite. This allowed for the potential of a seamless expansion to Vue as a frontend framework

for other site pages, as well as later inclusion of an Express backend with a Prisma ORM and

PostreSQL database. The decisions made to arrive on these were discussed, as well a s an overview

of the architecture created. Lastly, key problems encountered in the process are given, as well as

corresponding solutions or workarounds.

6 Evaluation

This chapter describes the process of an experimental evaluation of the new WebBlocks system.

Demographics and backgrounds of participants are described, and quantitative measures of task

performance using the site are given. Finally, survey responses on usability and favourability are

discussed, as well as changes in user perceptions on ability and enjoyability of web programming

after use of the system.

6.1 Methodology

In total, 16 participants completed a remote experiment where they were asked to complete tasks

within their own time and answer a series of survey questions concerning their perceptions and

opinions of the WebBlocks system, as well as providing information on their demographics and

past experiences with programming.

Two cohorts were subsequently deﬁned, between which results from the survey questions and

task performances were compared;

Inexperienced users: Those who report very little experience or less with programming in

HTML/CSS.

Experienced users: Those who report at least some experience with programming in

HTML/CSS.

This methodology was used due to constraints on availability for performing the experiment due

to the limited timeline and scope of the project. However, one issue with this is that participants

were unsupervised, so reports of task success are subject to uncertainty surrounding correctness.

This is balanced somewhat by Task 7 requiring users to provide their output from the system

directly, though it is possible that - particularly for experienced participants - some could avoid

the use of the WebBlocks interface entirely over a local programming editor.

A pre-survey and post-survey were also used to collect users’ wider attitudes towards programming

before and after use of the system. Surveys were formed of a mix of open ended responses and

Likert scale questions on a 5 point scale with randomised question order and response direction.

6.2 Participant Demographics and Background

Before performing the required tasks, participants were a sked to provide their consent for

inclusion in the research - shown in Figure C.4. Participants were then prompted to describe

their background in programming.

Figures C.6 and C.7 show experience with programming in HTML and CSS, reported from

’none’ to ’highly experienced’, forming the cohorts described in the methodology above. Six

participants featured in the inexperienced cohort, whereas ten were present in the experienced

group - this imbalance was due to availabilities of individual respondents given the time constraints

of the project; future work could see evaluation among greater numbers.

(a)

Programming and web develop-

ment experience across participants.

(b)

Programming and web develop-

ment experience in inexperienced co-

hort.

(c)

Programming and web develop-

ment experience in experienced cohort.

Figure 6.1:

Figure (a) shows participants’ higher educational or employment background in either

programming or web development. Figure (b) shows this within the inexperienced cohort - deﬁned as very

little experience or less in HTML/CSS - while Figure (c) shows this within the experienced cohort - with

at least some experience in HTML/CSS.

Highest past educational or employment background with programming, and particularly web

programming, is provided in Figure 6.1 - notably, one participant who reported very little

experience with HTML and CSS had studied as a student in Software Engineering, which could

suggest a need for a more reliable structured instrument for experience with the languages in

future experimentation, as reported experience is relative to the individu al.

Experience with the block-based programming modality, visualised in Figure 6.2, was also

provided. In the inexperienced group, none had used these, whereas more than 50% of those in

the experienced cohort had made use of the technologies; in fact, one participant had answered in

their past experience that they were a Scratch instructor. Basic demographic information on age

and gender were also collected, displayed in Figures C.8 and C.9 respectively. This showed a mix

among participants across genders, however women were dominant among the inexperienced

cohort, whereas men were in the experienced group. Another issue is that due to ethical and time

constraints of the project, it was not possible to test the product within its target demographic of

younger audiences, so those 25 or older were most prevalent.

6.3 Results

6.3.1 Task Results

Data overall pointed towards the successful implementation of various site functionality, however

these results showed disparities between the inexperienced and experienced cohorts. In Figure

6.3, it can be seen that around 90% and 80% of participants overall were able to complete tasks

adding structural code and style rules respectively, which indicates that requirements M1 and

S3 have been met. When looking at these performances within each experience group, it is

revealed that around 30% and 50% of inexperienced participants failed to carry out these essential

functions. Similarly, Figure C.10 shows that just over 80% of those across the two cohorts were

able to successfully ﬁnd the outputs of their compiled code and rendered site preview, suggesting

an adequate f acilitation of requirements M4 and M5. Again, however, within the inexperienced

group, 50% did not see this success. Figure C.11a shows approximately 90% of respondents were

(a)

Participants’ experience with the

block-based programming modality.

(b)

Block-based programming experi-

ence in inexperienced cohort.

(c)

Block-based programming experi-

ence in experienced cohort.

Figure 6.2:

Figure (a) shows participants’ experience with coding in the block-based programming modality.

Figure (b) shows this speciﬁcally within the inexperienced cohort - deﬁned as very little experience or less in

HTML/CSS - while Figure (c) shows this within the experienced cohort - with at least some experience

in HTML/CSS.

(a) Results for task one on adding structure blocks.

(b) Results for task two on adding style blocks.

Figure 6.3:

Figure (a) shows results for task one of self reported success in adding a paragraph to the page.

Figure (b) shows results for task two of self reported success in adding a new style rule to change the colour

of the paragraph on the page.

able to resize the windows of the editor, initially indicating the successful fulﬁlment of S11, while

a third of those in the inexperienced group were unable to do so. Open-ended responses revealed

though that the strip of the editor to control these widths was too narrow to perform this easily

- additionally, the failures in the less technical group hint that more visual aﬀordance could be

given to who may unfamiliar with this convention. Lastly, Figure C.11b shows that only one

participant was unable to recover the progress of their work after closing their tab in the browser,

which shows promising results for the provision of requirement S13. One reason for this outlier

could be that it was not speciﬁed in the task instructions whether to use an incognito browser or

not; as progress is stored in local storage in the browser, use of a private tab would mean that

progress would not be saved. Experimentation with a further developed product using a database

could show improvements in this area.

Each task was successfully completed by all experienced participants, with errors only in the

inexperienced cohort. An explanation for these disparities is reﬂected in open-ended responses

from one participant, which noted that task instructions were left unspeciﬁc as they did not

contain exact steps. This was done to simulate the conditions of a new user, who would likely

(a)

Results for task seven on reproducing the HTML of a

given web page.

(b)

Results for task seven on reproducing the CSS of a

given web page.

Figure 6.4:

Figures (a) and (b) show results for task seven of self reported success in reproducing the

structure and style of a website presented to participants.

not have such clear steps, but rather would rely on self-experimentation. Therefore, a promising

interpretation of the results could argue that the system allows at least 50% of users to complete

these tasks without any instruction or prior experience in programming HTML or CSS. Later

research could investigate how this compares to the traditional text-based modality. Additionally,

the low sample size in the inexperienced cohort may be inﬂuencing these results, as particular

struggles by some are overrepresented compared to within the more experienced group. Lastly,

due to the unobserved remote nature of the experiment, it is not clear whether some tasks would

even be possible for any given participant. For example, if a user had not added any blocks

successfully, then they would not be able to recover their work. This could create cascades of

failures within the results, ampliﬁed by the low sample size mentioned. Taken together, these

ﬁndings suggest that this early prototype shows a promising ability to allow novice users to

carry out basic web programming tasks without any prior experience, assistance or instruction.

However, further development eﬀort is necessary to make these tasks easily accessible for all,

particularly given that the target users of the website would be much younger.

A further task was given to participants to reproduce a page’s style and structure given a photo of

a basic website. Figure 6.4 shows the success rate of users carrying out this task for the structure

and style of the page respectively. These show no mistakes in the nested structure of the DOM

made in any of these submissions. It is reasonable to conclude, therefore, that the block-based

programming paradigm was eﬀective in preventing these basic errors (M3). Only one user was

unable to build the structure of the page; a further two interestingly made mistakes that are not

strictly errors in HTML, but rather misconﬁgurations under typical conventions. One had placed

their title element in the body of the page, rather than the head; another put their unordered

and ordered lists outside the body block. This points to the need for further development to

include a feature limiting the options for where a block can be added to only those which would

be correct under these best practices. A ﬁnal user made a mistake in using a <h3> tag instead

of a paragraph; one solution to this could be providing better visualisations of the outputs of

elements within their blocks in the programming editor to provide more visual aﬀordance. It is

also worthwhile noting that beginners did not make signiﬁcantly more mistakes than experienced

programmers - this highlights the potential for this technology to lower the threshold for entry

into web programming. From analysis of mist akes made in the page style, it appears that users

may struggle with ﬁnding or understanding selectors in style rules. One user was unable to

make an attempt at the task, but the other two found diﬃculties with applying a style rule to

the unordered list which they successfully added to the structure. This indicates that it may be

helpful for users to have more visual aﬀordance in the selectors presented for use in style rules to

better identify and understand these elements and their purpose.

Figure 6.5:

Results from the survey question on user perceptions of the understandability of the language

and terms used in the interface and blocks of WebBlocks, displayed as totals and dierences between the

inexperienced and experienced cohorts.

6.3.2 Perceptions in Survey Responses

Figure 6.5 shows that users found it somewhat easy to understand the langu age and terms used

across WebBlocks in its interface and blocks (mean=3.81, median=4). This indicates that Web-

Blocks oﬀers a fairly plain-English language (M2). These results were lower in the inexperience

group (mean: 3<4.3; median: 3<4.5), however a two-tailed Mann-Whitney U test showed that

these diﬀerences were not signiﬁcant (p=0.07). This indicates that further work should be done to

reﬁne this language set to ensure that it is accessible particularly for novice and younger learners.

This is reﬂected in the comments of one inexperienced participant shared that they felt the terms

used were based on the ’established language of web development’ - future research is needed

to investigate this in more detail to ﬁnd a core shared language appropriate for all ages and

experience levels. In open ended responses, both inexperienced and experienced participants

share a desire for ’tooltips’, ’examples’, or ’guides’, which oﬀers potential solutions to aid this

experience gap to overcome initial unfamiliarity.

In Figure C.12, it can be seen that WebBlocks achieves suﬃcient responsiveness (M6) as measured

by user perceptions (mean=3.86, median=4) - diﬀerences between the cohorts are not signiﬁcant

(p=0.059). This is supported by comments from participants which generally found preview

updates to feel instantaneous - one participant found this to provide helpful feedback on their

programming, while another claimed this to be ’honestly easier than actually programming’.

Figure C.13 shows that users did not perceive warnings to be particularly helpful, but they

also did not make the experience more diﬃcult (mean=2.94, median=3). Inexperienced users

did ﬁnd them more assistive than experienced users (mean: 3.5>2.6, median: 3.5>3) though

these diﬀerences were not signiﬁcant. One possible reason for this neutral appraisal is that in

open-ended responses, six of the participants noted that they did not see any warnings - this is

likely due to avoiding circumstances that arise these, such as choosing a pre-combined page block

which included a stylesheet import. Open ended responses provide a more optimistic outlook -

one claimed that when missing their style import, the warning ’clued [them] into the problem

and allowed [them] to solve it’ - when prompted with this same issue, another said they ’didn’t

quite get what the warning meant but it prompted [them] to go and ﬁgure out how to ﬁx the

issue’. Taken together, these results show that warnings are supporting users in their tasks (S6),

but a greater variety of warnings with simpler vocabulary should be used to increase the utility

of such a feature.

Users found it easy (mean=4.06, median=4.5) to ﬁnd elements in the toolbox, which suggests

Figure 6.6:

Results from the survey question on user perceptions of the realism of programming in

WebBlocks compared to a traditional text-based modality for HTML and CSS, displayed as totals and

dierences between the inexperienced and experienced cohorts.

that the categorised approach of organisation is eﬀective (S8) - this is shown in Figure C.14.

Further responses showed general agreement with this sentiment, but some participants oﬀer

suggestions for improvement - one oﬀers that categories should be ordered by frequency of usage

and another proposes that categories could be broken better into sub-categories. However, a

third user indicates confusion with the diﬀerentiation between statements and selectors, so more

visual aﬀordance could be provided using clues other than shape, as well as by providing tool tips

as noted again in one response.

Pre-combined blocks were found by users to be helpful/very helpful (S9) (mean=4.56, median=5)

- this is visualised in Figure C.15. These were described as providing a positive experience by

reducing the eﬀort required by users, as well as ’making it clear how one might put those elements

together’, to ’base work oﬀ’. In fact, one user requested precombined style rules so that they

could more easily understand the correct structure of these.

Users seemed to believe that the editor could handle a suﬃcient number of blocks for them to

build their website, with a mix of feedback averaging between ’no strong opinion’ and ’suﬃcient’

(mean=3.88, median=3.5) - this is displayed in Figure C.16 (M7).

Finally, users were also asked how realistic to programming they found the WebBlocks system to

be, seen in Figure 6.6. Inexperienced users on average found the system to be more realistic than

the experienced cohort (mean: 4>3.6; median: 4.5>4), though not signiﬁcantly (p=0.22) - overall

the system was held to be somewhat realistic. This is encouraging considering the context of the

site’s intended use among more novice learners, who may not be attracted to it if they felt that it

didn’t hold real-world use.

6.3.3 Pre-Survey and Post-Survey Changes in Attitudes

Some of the most interesting ﬁndings of this experiment can be found in the changes in responses

in the pre-surveys and post-surveys. Wilcoxon signed-rank tests showed that participants in both

the inexperienced and experienced cohorts reported a signiﬁcant increase in their perception

of their ease in programming websites (p=0.03125, p=0.003906 respectively) - this is shown in

Figure 6.7. This coincides with a signiﬁcant improvement in conﬁdence in web programming

seen in Figure C.20 within the experienced group (p=0.03125) as well as an increase in the

inexperienced group, though this was found not to be statistically signiﬁcant. This suggests that

use of WebBlocks in the experiment was associated with improved self-eﬃcacy beliefs, which

aid persistence in coding. Similarly, participants saw an increase in enjoyment and likeliness to

(a) Signiﬁcant increase in perception of ease of coding websites in inexperienced users.

(b) Signiﬁcant increase in perception of ease of coding websites in experienced users.

Figure 6.7:

Figures (a) and (b) show statistically signiﬁcant increases between pre-surveys and post-surveys

in self-reported perceptions of users’ ease of programming websites in both inexperienced and experienced

cohorts respectively.

program websites again - displayed in Figures C.19 and C.18 - though these gains were not

signiﬁcant. Overall, respondents showed an increase in means across every category of these

attitudinal values in both the inexperienced and experienced groups. This is illustrated in Figure

C.17. Although not all of these results show signiﬁcant increases, a lack of statistical power due

to the reduced sample size of the experiment might arise a need to investigate these attitudes in a

more robust setting.

6.4 Summary

Participants completed a number of tasks making use of essential functionality of the system,

and then answered Likert scale and open-ended survey questions. Findings generally showed

a somewhat successful prototype implementation of M1-7, S2-3, S6, S8-9, S11, S13, though

there is room for further work in developing these features to ensure that these results could

be applicable for the younger targeted demographic. Most interestingly, it was found that both

inexperienced and experienced users experienced an increase in mean conﬁdence in ability,

enjoyment, and ease of web programming, as well as likeliness to program a website again. This

included a statistically signiﬁcant increase in perception of ease of web programming in both

cohorts, and in conﬁdence in the experienced group. Underlining all of this, however, is a need

for further examination in a more rigorous manner due to weaknesses in methodology resulting

from the project’s resource limitations.

7 Conclusion

This chapter provides an overview of the WebBlocks application which has been implemented

over the course of the project, and key ﬁndings of its evaluation are revisited. Reﬂection is made

on the progress of the development and the decisions made throughout, as well as areas which

may have beneﬁted from a diﬀerent approach. Lastly, suggestions for future work are given.

7.1 Summary

WebBlocks, a new block-based programming environment for web development languages,

was produced to oﬀer an accessible and engaging entry point to coding. To be suitable as a ﬁrst

exposure to programming under a spiral curriculum approach, the editor presents HTML and

CSS code in a plain-English language. The system allows users to program HTML and CSS in

separate environments, while viewing a live preview of their site and its rendered code.

An experimental evaluation was performed which generally showed very strong usability among

experienced users, and fair usability among inexperienced ones. Most interestingly, users showed

statistically signiﬁcant increases after use of WebBlocks in perceptions of ease of web programming

in both experienced and inexperienced cohorts, as well as a signiﬁcant increase in conﬁdence in

the experienced group.

7.2 Reﬂection

The biggest constraint on the development of this project was the limited time available. I would

have loved to create a more comprehensive solution of the possible features discussed, as this

could potentially oﬀer an engaging and widely accessible introduction to coding for children.

Further, I would have liked to implement multiple abstraction layers over the language used as

this could oﬀer novel contributions to the research community. I also would have been interested

to see this system tested in classrooms in the real world, as this could evaluate its eﬀectiveness

more reliably. If I was to ﬁnd myself again at the beginning of the project, I would have written

a more extensible architecture for the l anguage used in blocks, and their translations to code. I

would use inheritance and implementations of interfaces to ensure that new abstraction layers

could be seamlessly added without disruption to the overall structure of the system.

7.3 Future work

One direction for future work is a fuller implementation of the design solution for the block-based

programming editor, taking into account ﬁndings from the experimental evaluation. This could

be supplemented by experimental research into the clarity of the common language of web

programming concepts, as well as a translation of these terms into words that are easier for novices

to understand, without negatively impacting later learning. Additionally, a wider range of block

types could allow students to develop more advanced websites while pursuing project-based

learning. Similarly, features could be explored to expand the utility and enjoyment of the site,

Figure 7.1: Overview of the ﬁnal WebBlocks interface being used to code a basic website.

such as the ability for users to publish their sites, as well as including gamiﬁcation concepts to

support learning like levels where users are asked to recreate website pages shown to them. Kim

(2021) notes that JavaScript is often harder to learn due to its procedural nature, and therefore

presents further diﬃculties in the initial stages of study. WebBlocks could be extended to facilitate

the coding of site functionality using JavaScript to support learners to visit this language at a

simple initial level as is recommended under a spiral curriculum. Additionally, W3C XHTML

and CSS validation of adherence of syntax to conventions could be used - as discussed in Stepp

et al. (2009) - to ensure that students are taught good habits from their ﬁrst exposure to web

programming.

Currently, WebBlocks aims to support a spiral curriculum by providing a new accessible starting

point in basic web programming for young learners. An undiscovered area in the literature is

the use of programming tools which support multiple block-based abstraction layers, similar to

the extensible programming language created in Hermans (2020). This was discussed in the

design solution, and could allow users to reach higher levels of experience with less diﬃculty.

This path may see the tool’s most valuable contributions to the research community, as well as to

the market for novices.

Another possible avenue for further work is a more robust evaluation of the practical applications

of WebBlocks. As a system designed primarily for younger users, it would be valuable to test

the site within a classroom setting with real novices in the target demographics. This could

include more rigid experimental protocols, wider sample sizes, and standardised instrumentation

for measuring past experience with web programming in order to compare experienced and

inexperienced cohorts reliably. It would be most interesting to see if the improvements in attitudes

towards programming following the use of the system would hold true in these demographics, as

this could make a very compelling case for the use of WebBlocks in the earliest stages of learning.

A Additional Design Wireframes

Figure A.1:

Wireframe of a user’s view of existing projects, with options to open, duplicate or delete

individual projects or edit their details.

Figure A.2: Wireframe of view of published site with appended footer.

B Additional Implementation Figures

Figure B.1:

Diagram of interaction between the two workspaces for HTML and CSS and their respective

block toolboxes.

Figure B.2: Code created with blocks by the user is compiled into separate CSS and HTML ﬁles.

Figure B.3:

A warning is displayed above users’ style rules, notifying them that they haven’t included a

stylesheet so the rules cannot be applied.

Figure B.4:

HTML code uses CSS style rules through the inclusion of a ’Stylesheet’ block in the metadata

of the page.

Figure B.5: Structure of plain-language block deﬁnitions for HTML and CSS.

C Evaluation

C.1 Experiment Questions

1. What is your age?

• 18-24

• 25-34

• 35-44

• 45+

• Prefer not to say

2. What is your gender?

• woman

• man

• non-binary

• prefer not to disclose

• prefer to self-describe:

3. If any, how much experience do you have with programming in HTML/CS S?

• No experience

• Very little experience

• Some experience

• Moderate experience

• Highly experienced

4. If any, how much experience do you have with block-based programming tools (like Scratch,

MIT App Inventor, Micro:Bit MakeCode)?

• No experience

• Very little experience

• Some experience

• Moderate experience

• Highly experienced

5. Do you have any higher educational/occupational experience with programming or web

design/development?

• Student, computing science

• Student, software engineering

• Student, other: (Please specify)

• Employment, web developer

• Employment, software developer

• Employment, other: (Please specify)

• Other: (Please specify)

• None

7. How conﬁdent or unconﬁdent do you feel in web programming?

• Very Conﬁdent

• Conﬁdent

• Neutral/No strong Opinion

• Unconﬁdent

• Very Unconﬁdent

8. How likely or unlikely would you be to program websites again? (Either block-based

programming or coding with HTML/CSS)

• Very Likely

• Likely

• Neutral/No strong Opinion

• Unlikely

• Very Unlikely

9. What is your perception of your enjoyment of programming websites?

• Very Enjoyable

• Enjoyable

• Neutral/No strong Opinion

• Unenjoyable

• Very Unenjoyable

10. What is your perception of your ease or diﬃculty of programming websites?

• Very Easy

• Easy

• Neutral/No strong Opinion

• Diﬃcult

• Very Diﬃcult

WebBlocks

For the following questions, please use the WebBlocks site, available at https://lilyﬂeetingcraig.github.io/dissertation/.

Task 1 - Intro to Programming Site Structure

Navigate the block-based programming editor to add a new website page, and add a paragraph.

11. Please conﬁrm if the paragraph successfully appears in the preview of your website in the left

hand panel.

• I have added a paragraph.

• I have been unable to add a paragraph.

Task 2 - Intro to Programming Site Style

Access the ’Style’ tab in the block-based programming editor, and add a new style rule to change

the text colour of your paragraph to red. Follow any warnings to ensure you can see this colour

change in the preview.

12. Please conﬁrm if the paragraph successfully appears as red in the preview.

• I have changed the colour of the paragraph.

• I have been unable to change the colour of the paragraph.

Task 3 - View your Compiled Code

Navigate the interface to view the preview of your compiled code as raw HTML and CSS.

13. Please conﬁrm if you have successfully found your compiled code.

• I have found the preview of the compiled website code.

• I have not found the preview of the compiled website code.

Task 4 - View your Website Preview

Navigate the interface to return to the preview of your website page showing your coloured

paragraph.

14. Please conﬁrm if you have successfully found your compiled code.

• I have found the preview of the website.

• I have not found the preview of the website.

Task 5 - Resizing Editor Panels

Resize the panels in the editor to shrink the website preview.

15. Please conﬁrm if you have successfully shrunk the website preview panel.

• I have successfully shrunk the preview of the website.

• I have not successfully shrunk the preview of the website.

Task 6 - Recovering Your Project

Please close the WebBlocks t ab in your browser, and revisit the site.

Remember that this site is available at https://lilyﬂeetingcraig.github.io/dissertation/.

16. Please conﬁrm if the code for your web page with your coloured paragraph is still visible in

the editor.

• I can see my recovered project.

• I can no longer see my recovered project.

Task 7 - Building a Specimen Website

Please ﬁrst delete your current code for your website if any exists by moving it to the bin.

17. Then, please use your skills in the editor to recreate the website below.

You may use the following link as an example image: https://i.postimg.cc/B6fm0M0P/image.png

[Example Photo by Joe Caione on Unsplash]

Please navigate to the compiled code preview panel, and copy and paste the content of both the

index.html and style.css ﬁles below.

index.html:

style.css:

WebBlocks Survey

Please feel free to continue experimenting with WebBlocks, and now complete the following

questions on your experiences in your use of the system.

18. Following your use of the WebBlocks system, how conﬁdent or unconﬁdent do you feel in

web programming?

• Very Conﬁdent

• Conﬁdent

• Neutral/No strong opinion

• Unconﬁdent

• Very Unconﬁdent

19. Following your use of the WebBlocks system, how likely or unlikely would you be to

program websites again? (Either block-based programming or coding with HTML/CSS)

• Very Likely

• Likely

• Neutral/No strong opinion

• Unlikely

• Very Unlikely

20. Following your use of the WebBlocks system, overall what is your perception of your

enjoyment of programming websites?

• Very Enjoyable

• Enjoyable

• Neutral/No strong Opinion

• Unenjoyable

• Very Unenjoyable

21. Following your use of the WebBlocks system, overall what is your perception of your ease or

diﬃculty of programming websites?

• Very Easy

• Easy

• Neutral/No strong Opinion

• Diﬃcult

• Very Diﬃcult

22. How realistic or unrealistic did you ﬁnd programming using WebBlocks?

• Very Realistic

• Realistic

• Neutral/No strong Opinion

• Unrealistic

• Very Unrealistic

23. How did you ﬁnd the language and terms used in the interface and blocks?

• Very Easy to Understand

• Easy to Understand

• Neutral/No strong opinion

• Diﬃcult to Understand

• Very Diﬃcult to Understand

24. Do you have any comments on the language and terms used in the interface and blocks?

E.g., is there anything missing? Do you have any suggestions to improve this? Did you have any

particular diﬃculties?

25. How did you ﬁnd the automatic updates in the preview of your website when you edited the

block code?

• Too fast

• Suﬃciently fast

• Neutral/No strong Opinion

• Suﬃciently slow

• Too slow

26. Do you have any comments on the responsiveness of the automatic updates in the preview of

your website when you edited the block code? E.g., is there anything missing? Do you have any

suggestions to improve this? Did you have any particular diﬃculties?

27. How was your experience of warnings in the editor?

• Very Helpful

• Helpful

• Neutral/No strong Opinion

• Unhelpful

• Very Unhelpful

28. Do you have any comments about the warnings displayed in the editor? E.g., is there anything

missing? Do you have any suggestions to improve this? Did you have any particular diﬃculties?

29. How was your experience of ﬁnding elements categorised in the toolbox?

• Very Easy to Find

• Easy to Find

• Neutral/No strong Opinion

• Diﬃcult to Find

• Very Diﬃcult to Find

30. Do you have any comments on your experience of ﬁnding elements categorised in the

toolbox? E.g., is there anything missing? Do you have any suggestions to improve this? Did you

have any particular diﬃculties?

31. How was your experience of using precombined selections of elements in the toolbox?

• Very Helpful

• Helpful

• Neutral/No strong opinion

• Unhelpful

• Very Unhelpful

32. Do you have any comments on your experience of using precombined selections of elements

in the toolbox? E.g., is there anything missing? Do you have any suggestions to improve this?

Did you have any particular diﬃculties?

33. What is your opinion on the number of blocks the editor can handle before noticing any

degradation of performance, if any?

• Very Suﬃcient

• Suﬃcient

• Neutral/No strong opinion

• Insuﬃcient

• Very Insuﬃcient

34. Do you have any ﬁnal comments? E.g., is there anything missing from the system? Do you

have any suggestions to improve it? Did you have any particular diﬃculties?

C.2 Ethics Checklist

School of Computing Science

University of Glasgow

Ethics checklist form for assessed exercises (at all levels)

This form is only applicable for assessed exercises that use other people (‘participants’) for the collection

of information, typically in getting comments about a system or a system design, or getting information

about how a system could be used, or evaluating a working system.

If no other people have been involved in the collection of information, then you do not need to

complete this form.

If your evaluation does not comply with any one or more of the points below, please contact the Chair of

the School of Computing Science Ethics Committee (matthew.chalmers@glasgow.ac.uk) for advice.

If your evaluation does comply with all the points below, please sign this form and submit it with your

assessed work.

1. Participants were not exposed to any risks greater than those encountered in their normal working

life.

Investigators have a responsibility to protect participants from physical and mental harm

during the investigation. The risk of harm must be no greater than in ordinary life. Areas of

potential risk that require ethical approval include, but are not limited to, investigations that

occur outside usual laboratory areas, or that require participant mobility (e.g. walking,

running, use of public transport), unusual or repetitive activity or movement, that use sensory

deprivation (e.g. ear plugs or blindfolds), bright or flashing lights, loud or disorienting noises,

smell, taste, vibration, or force feedback

2. The experimental materials were paper-based, or comprised software running on standard hardware.

Participants should not be exposed to any risks associated with the use of non-standard

equipment: anything other than pen-and-paper, standard PCs, laptops, iPads, mobile phones

and common hand-held devices is considered non-standard.

3. All participants explicitly stated that they agreed to take part, and that their data could be used in the

project.

If the results of the evaluation are likely to be used beyond the term of the project (for

example, the software is to be deployed, or the data is to be published), then signed consent is

necessary. A separate consent form should be signed by each participant.

Otherwise, verbal consent is sufficient, and should be explicitly requested in the introductory

script.

4. No incentives were offered to the participants.

The payment of participants must not be used to induce them to risk harm beyond that which

they risk without payment in their normal lifestyle.

Figure C.1: Signed ethics checklist.

5. No information about the evaluation or materials was intentionally withheld from the participants.

Withholding information or misleading participants is unacceptable if participants are likely to

object or show unease when debriefed.

6. No participant was under the age of 16.

Parental consent is required for participants under the age of 16.

7. No participant has an impairment that may limit their understanding or communication.

Additional consent is required for participants with impairments.

8. Neither I nor my supervisor is in a position of authority or influence over any of the participants.

A position of authority or influence over any participant must not be allowed to pressurise

participants to take part in, or remain in, any experiment.

9. All participants were informed that they could withdraw at any time.

All participants have the right to withdraw at any time during the investigation. They should be

told this in the introductory script.

10. All participants have been informed of my contact details.

All participants must be able to contact the investigator after the investigation. They should be

given the details of both student and module co-ordinator or supervisor as part of the

debriefing.

11. The evaluation was discussed with all the participants at the end of the session, and all participants

had the opportunity to ask questions.

The student must provide the participants with sufficient information in the debriefing to

enable them to understand the nature of the investigation. In cases where remote participants

may withdraw from the experiment early and it is not possible to debrief them, the fact that

doing so will result in their not being debriefed should be mentioned in the introductory text.

12. All the data collected from the participants is stored in an anonymous form.

All participant data (hard-copy and soft-copy) should be stored securely, and in anonymous

form.

Course and Assessment Name Individual Project Evaluation

Student’s Name Lily Fleeting-Craig

Student Number 2622842c

Student’s Signature ________________________

Date 12/08/2026

Ethics checklist for assessed exercises

Figure C.2: Signed ethics checklist (cont).

C.3 Participant Brieﬁng and Consent Sheet

Participant Brieng & Consent

Researcher

Lily Fleeting-Craig, Level 4 Computing Science student, School of Computing Science,

University of Glasgow

Supervisor

Fionnuala Johnson, Lecturer, School of Computing Science, University of Glasgow

What is this study about?

This study is evaluating WebBlocks, a new website aimed to make coding in HTML and CSS

easier and more fun for new learners using block-based programming. Block-based

programming allows you to code by dragging blocks of code together, connecting them like

puzzle pieces - you might have used this before in sites like Scratch, Micro:Bit MakeCode, or MIT

App Inventor. The experiment focuses on testing whether the core features of the site are t for

purpose, as well as investigating perceptions on usability, enjoyment, and understandability.

What will I be asked to do?

Firstly, consent for participation in the experiment will be taken ensuring that you t core

criteria, and basic demographic information and experience with block-based programming and

web programming will be taken. You will be asked to complete a series of short tasks to perform

basic actions on the WebBlocks site to evaluate the performance of several core features, as

well as one longer form task where you will be asked to share your output. These tasks do not

measure your ability to carry out these actions, but are evaluating the success of the

implementation of the features. You will lastly be asked to provide some opinions on your

experience using the site.

This should take about 10-20 minutes in total.

Do I have to take part?

Your participation in this experiment is voluntary, and you are free to withdraw your participation

at any time by closing the browser window before completing your response - note that if you do

withdraw before the completion of the survey, you will not be given the chance to debrief. You

may also withdraw from the experiment before the 17th of August, however after this time data

collected will be anonymised and aggregated and included in the evaluation of the product.

Figure C.3: Participant brieﬁng for experimental evaluation and consent sheet.

Are there any risks or benets?

There are not any known risks associated with participation in this experiment beyond normal

computer use. You will not receive any compensation for your participation.

Condentiality and data use

Your responses to these questions are anonymous - however, please do not enter any

personally identiable information either in the photo of your WebBlocks project, or in any of the

questions or task answers in the survey.

Data will be anonymised and aggregated, and presented in the report for this evaluation. These

results and quotes from survey questions may also be presented in future research on this tool.

Data will be stored securely for the duration.

Important notes / Disclaimer

The tasks conducted in this study are measures of the eectiveness and usability of the

WebBlocks interface, and do not represent an assessment of your abilities in problem-solving,

programming, or block-based programming.

Contact

If you do have any questions, please feel free to contact the researcher for this project at the

following email address:

2622842C@student.gla.ac.uk

Alternatively, you may contact the supervisor of this project:

Fionnuala Johnson

Fionnuala.Johnson@glasgow.ac.uk

Consent

By signing below, you conrm that:

- You are aged 16 or over.

- You have read and understood the information above.

- You do not have any impairment that may limit your understanding or communication.

- You agree to take part in this study.

Your Name_____________________________________________________________________________

Date____________________________________________________________________________________

Figure C.4: Participant brieﬁng for experimental evaluation and consent sheet (cont).

Participant Debrief

Thank you for your time participating in this survey - your contributions to this experiment are

valued. This experiment has been investigating the usability of a new block-based programming

editor for web languages, WebBlocks. Eectiveness and usability of individual features are

measured by aggregate task completion rates - note that these measure the implementation of

the system, and not your individual ability. Survey responses are then considered to evaluate

the preferability and ease of use of the interface.

Researcher

Lily Fleeting-Craig, Level 4 Computing Science student, School of Computing Science,

University of Glasgow

Project Supervisor

Fionnuala Johnson, Lecturer, School of Computing Science, University of Glasgow

Contact

If you have any questions or comments following the experiment, please feel free to contact the

researcher at the following email address:

2622842c@student.gla.ac.uk

Or you can contact the project supervisor at the following email address:

Fionnuala.Johnson@glasgow.ac.uk

Figure C.5: Participant debrief following experiment.

C.4 Additional Demographics Visualisations

Figure C.6:

Spilt of participants across two cohorts by self-reported experience level with HTML and

CSS - those with at least some experience were deﬁned as experienced, and those without as inexperienced.

(a)

HTML/CSS experience in inexperienced cohort.

(b) HTML/CSS experience in experienced cohort.

Figure C.7:

Figure (a) shows experience with HTML and CSS in the inexperienced cohort - deﬁned as

very little experience or less - while Figure (b) shows this within the experienced cohort - with at least

some experience.

(a)

Age demographics of experiment

participants.

(b)

Age demographics of the inexperi-

enced cohort.

(c)

Age demographics of the experi-

enced cohort.

Figure C.8: Figure (a) shows age demographics aggregated across all experiment participants. Figure (b)

shows this split in the inexperienced cohort, whereas Figure (c) shows this within the experienced cohort.

(a)

Gender demographics of experi-

ment participants.

(b)

Gender demographics of the inex-

perienced cohort.

(c)

Gender demographics of the expe-

rienced cohort.

Figure C.9:

Figure (a) shows gender demographics aggregated across all experiment participants. Figure

(b) shows this split in the inexperienced cohort, whereas Figure (c) shows this within the experienced cohort.

C.5 Additional Results Visualisations

C.5.1 Task Results

(a) Results from task three on viewing compiled code. (b) Results from task four on viewing site preview.

Figure C.10:

Figure (a) shows results for task three of self reported success in navigating the interface to

view the compiled code output. Figure (b) shows results for task four of self reported success in navigating

the interface to view the rendered preview of the site.

(a) Results from task ﬁve on resizing editor panels.

(b) Results from task ﬁve on recovering the project.

Figure C.11:

Figure (a) shows results for task ﬁve of self reported success in resizing the editor panels.

Figure (b) shows results for task six of self reported success in recovering project progress when closing and

reopening the browser.

C.5.2 Additional Survey Question Response Visu alisations

Figure C.12:

Results from the survey question on the suitability of the responsiveness of the automatic

updates to the site preview output, displayed as totals and dierences between the inexperienced and

experienced cohorts.

Figure C.13:

Results from the survey question on the helpfulness of warnings displayed in the editor to aid

users to carry out their tasks, displayed as totals and dierences between the inexperienced and experienced

cohorts.

Figure C.14:

Results from the survey question on the ﬁndability of blocks organised in categories in the

toolbox, displayed as totals and dierences between the inexperienced and experienced cohorts.

Figure C.15:

Results from the survey question on the helpfulness of the structured pre-combined blocks in

the toolbox to aid users to carry out their tasks, displayed as totals and dierences between the inexperienced

and experienced cohorts.

Figure C.16: Results from the survey question on the suitability of the number of blocks a user can add

to the editor before seeing any degradation in responsiveness, displayed as totals and dierences between the

inexperienced and experienced cohorts.

C.5.3 Increase in Attitudes between Pre-Surveys and Post-Surveys

Figure C.17:

Table showing an increase in means and medians in both the inexperienced and experienced

cohorts across the board in categories of conﬁdence, ease, enjoyment and likeliness to program websites.

(a) Increase in likeliness to code websites again in inexperienced users.

(b) Increase in likeliness to code websites again in experienced users.

Figure C.18:

Figures (a) and (a) show increases between pre-surveys and post-surveys in self-reported

perceptions of users’ likeliness to programme websites again in the future in both inexperienced and

experienced cohorts respectively, though these results are not signiﬁcant.

(a) Increase in perception of enjoyment of coding websites in inexperienced users.

(b) Increase in perception of enjoyment of coding websites in experienced users.

Figure C.19:

Figures (a) and (b) show increases between pre-surveys and post-surveys in self-reported

perceptions of users’ enjoyment of programming websites in both inexperienced and experienced cohorts

respectively, though these results are not signiﬁcant.

(a) Increase in conﬁdence in coding websites in inexperienced users.

(b) Signiﬁcant increase in conﬁdence in coding websites in inexperienced users.

Figure C.20:

Figure (a) shows an increase between pre-surveys and post-surveys in self-reported perceptions

of conﬁdence in programming websites in the inexperienced cohort, whereas Figure (b) shows a signiﬁcant

improvement in the experienced cohort.

Bibliography

Anaconda (2023), ‘Edublocks’, https://app.edublocks.org/. Accessed: 2026-07-20.

Armoni, M., Meerbaum-Salant, O. and Ben-Ari, M. (2015), ‘From scratch to “real” program-

ming’, 14(4), 1–15.

URL: https://dl.acm.org/doi/10.1145/2677087

Atlassian (2011), ‘Trello’, https://trello.com. Accessed: 2026-08-09.

Begel, A. (1996), Logoblocks: A graphical programming language for interacting with the world,

Undergraduate thesis, MIT Media Laboratory.

URL: https://andrewbegel.com/mit/begel-aup.html

Blockly (2026a), ‘Getting st arted with blockly’.

URL: https://docs.blockly.com/codelabs/getting-started/codelab-overview/

Blockly (2026b), ‘Resizable workspace’.

URL: https://docs.blockly.com/guides/conﬁgure/resizable/

Blockly (n.d.), ‘Customizing a blockly toolbox’.

URL: https://blocklycodelabs.dev/codelabs/custom-toolbox/index.html

Bruner, J. S. (1960), The Process of Education, Harvard University Press, Cambridge, MA.

Bruner, J. S. (1966), Toward a Theory of Instruction, Belknap Press of Harvard University Press,

Cambridge, MA.

Chen, C., Haduong, P., Brennan, K., Sonnert, G. and Sadler, P. (2019), ‘The eﬀects of ﬁrst

programming l anguage on college students’ computing attitude and achievement: a comparison

of graphical and textual languages’, 29(1), 23–48.

URL: https://www.tandfonline.com/doi/full/10.1080/08993408.2018.1547564

Code.org (2026), ‘Code.org’, https://code.org/en-US. Accessed: 3 August 2026.

Consortium, A. B. (2026), ‘What is MoSCoW prioritization?’.

URL: https://www.agilebusiness.org/resource/what-is-moscow-prioritization/

Conventional Commits (2019).

URL: https://www.conventionalcommits.org/en/v1.0.0/

ED-Info (2023), ‘Blocklyhtml’,

https://ed-info.github.io/blocklyhtml/

. Accessed:

2026-07-20.

Fraser, N. (2015), ‘Multi-blockly’.

URL: https://groups.google.com/g/blockly/c/EoCr5pbwKIY

GitHub (2026a), ‘Github actions’.

URL: https://github.com/features/actions

Github (2026b), ‘Github Pages’, https://pages.github.com. Accessed: 2026-08-09.

Google (2012), ‘Blockly’,

https://developers.google.com/blockly

. Accessed: 2026-07-

22.

Harvey, B., Mönig, J. and Ball, M. (2025), Snap! Reference Manual, Zenodo.

URL: https://doi.org/10.5281/zenodo.16892852

Hermans, F. (2020), Hedy: A gradual language for programming education, in ‘Proceedings of

the 2020 ACM Conference on International Computing Education Research’, ACM, pp. 259–

270.

URL: https://dl.acm.org/doi/10.1145/3372782.3406262

Hudaib, A., Masadeh, R., Qasem, M. H. and Alzaqebah, A. (2018), ‘Requirements prioritization

techniques comparison’, 12(2), 62.

URL: http://www.ccsenet.org/journal/index.php/mas/article/view/72718

International Institute of Business Analysis (2015), A Guide to the Business Analysis Body of

Knowledge (BABOK Guide), 3 edn, International Institute of Business Analysis.

James Long (2017), ‘Prettier - Opinionated Code Formatter’,

https://prettier.io

. Accessed:

2026-08-09.

Kalogiannakis, M., Tzagkaraki, E. and Papadakis, S. (2021), A systematic review of the use of

bbc micro:bit in primary school.

Kim, G., Debois, P., Willis, J. and Humble, J. (2016), The DevOps Handbook, IT Revolution.

Kim, M. C. (2021), Learning Early-Stage Web Development at Scale: Exploring Methods to Assess

Learning Through Analysis of HTML and CSS, Drexel University.

King’s College London (2022), ‘Strype’, https://strype.org. Accessed: 22 July 2026.

Kravchenko, T., Bogdanova, T. and Shevgunov, T. (2022), Ranking requirements using

MoSCoW methodology in practice, in R. Silhavy, ed., ‘Cybernetics Perspectives in Systems’,

Vol. 503, Springer International Publishing, pp. 188–199. Series Title: Lecture Notes in

Networks and Systems.

URL: https://link.springer.com/10.1007/978-3-031-09073-8

Kyfonidis, C., Moumoutzis, N. and Christodoulakis, S. (2017), Block-c: A block-based program-

ming teaching tool to facilitate introductory c programming courses, in ‘2017 IEEE Global

Engineering Education Conference (EDUCON)’, IEEE, pp. 570–579.

URL: http://ieeexplore.ieee.org/document/7942903/

Massachusetts Institute of Technology (2010), ‘Mit app inventor’,

https://appinventor.mit.

edu/. Accessed: 2026-07-20.

Microsoft (2016), ‘Microsoft makecode for micro:bit’,

https://makecode.microbit.org/

Accessed: 2026-07-20.

Mladenović, M., Boljat, I. and Žanko, (2018), ‘Comparing loops misconceptions in block-based

and text-based programming languages at the k-12 level’, 23(4), 1483–1500.

URL: http://link.springer.com/10.1007/s10639-017-9673-3

Nielsen, J. (1994), ‘10 usability heuristics for user interface design’.

URL: https://www.nngroup.com/articles/ten-usability-heuristics/

OpenJS Foundation (2026), ‘ESLint’, https://prettier.io. Accessed: 2026-08-09.

Rannikmäe, M., Holbrook, J. and Soobard, R. (2025), Social constructivism—jerome bruner,

in B. Akpan and T. J. Kennedy, eds, ‘Science Education in Theory and Practice’, Springer

Nature Switzerland, pp. 255–273. Series Title: Springer Texts in Education.

URL: https://link.springer.com/10.1007/978-3-031-81351-1

Scratch Foundation (2007), ‘Scratch’, https://scratch.mit.edu/. Accessed: 2026-07-20.

Scratch Foundation (2026), ‘Scratch statistics’.

URL: https://scratch.mit.edu/statistics/

Soudani, R. R., Mohamed Experts, A. A., Abdulgader, A. M. and Abdulgader, M. (2024), The

impact of code structure on programming ﬂuency for kids in programming languages, in

‘2024 International Conference on Computer and Applications (ICCA)’, pp. 1–5.

Statter, D. and Armoni, M. (2020), ‘Teaching abstraction in computer science to 7

grade

students’, 20(1), 1–37.

URL: https://dl.acm.org/doi/10.1145/3372143

Stepp, M., Miller, J. and Kirst, V. (2009), ‘A "CS 1.5" introduction to web programming’,

41(1), 121–125.

URL: https://dl.acm.org/doi/10.1145/1539024.1508908

Sun, D., Looi, C.-K., Li, Y., Zhu, C., Zhu, C. and Cheng, M. (2024), ‘Block-based versus

text-based programming: a comparison of learners’ programming behaviors, computational

thinking skills and attitudes toward programming’, 72(2), 1067–1089.

URL: https://link.springer.com/10.1007/s11423-023-10328-8

Sáez-López, J.-M., Román-González, M. and Vázquez-Cano, E. (2016), ‘Visual programming

languages integrated across the curriculum in elementary school: A two year case study using

“scratch” in ﬁve schools’, 97, 129–141.

URL: https://www.sciencedirect.com/science/article/pii/S0360131516300549

Tran, C., Fasiang, K., Kanwal, M. and O’Rourke, E. (2026), Starting from scratch again and again:

Tracing the origins of high schoolers’ negative perceptions of block-based programming, in

‘Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems’, ACM,

pp. 1–17.

URL: https://dl.acm.org/doi/10.1145/3772318.3791825

University of California, Berkeley (2010), ‘Sn ap!’,

https://snap.berkeley.edu/snap

. Ac-

cessed: 2026-07-20.

VoidZero Inc. (2026), ‘Vitest’, https://vitest.dev/. Accessed: 2026-08-09.

Weintrop, D. (2019), ‘Block-based programming in computer science education’,

(8), 22–25.

URL: https://dl.acm.org/doi/10.1145/3341221

Weintrop, D., Afz al, A., Salac, J., Francis, P., Li, B., Shepherd, D. C. and Franklin, D. (2018),

Evaluating CoBlox: A comparative study of robotics programming environments for adult

novices, in ‘Proceedings of the 2018 CHI Conference on Human Factors in Computing

Systems’, ACM, pp. 1–12.

URL: https://dl.acm.org/doi/10.1145/3173574.3173940

Weintrop, D. and Wilensky, U. (2018), ‘Comparing block-based and text-based programming

in high school computer science classrooms’, 18(1), 1–25.

URL: https://dl.acm.org/doi/10.1145/3089799

Weintrop, D. and Wilensky, U. (2019), ‘Transitioning from introductory block-based and text-

based environments to professional programming languages in high school computer science

classrooms’, 142, 103646.

URL: https://linkinghub.elsevier.com/retrieve/pii/S036013151930199X

Zeevaarders, A. and Aivaloglou, E. (2021), Exploring the programming concepts practiced by

scratch users: an analysis of project repositories, in ‘2021 IEEE Global Engineering Education

Conference (EDUCON)’, pp. 1287–1295.