[MUSIC]
Hello!
I'm Aaron Dodson.
I'm a software engineer at Google where I work on the website and infrastructure for
CS First along with Blockly where I've been focused on the migration to TypeScript.
Today I'm going to provide an overview of how we use Blockly at Google, discuss some
approaches for integrating Blockly into a larger app, and review some new instructional
design features that Blockly has enabled for us.
Before we begin, let me provide some background about Google CS First.
CS First is a computer science curriculum designed for students between the ages of
9 and 14 that aims to introduce them to programming and computer science concepts with a special
focus on students from historically underrepresented groups in computer science.
CS First guides students through building projects in Scratch, the popular block-based
programming environment, with a combination of videos and instructional content.
Scratch is built on Blockly, and in early 2021 we brought a version of Scratch in-house
in collaboration with the Scratch Foundation, which we call...
...Scratch for CS First.
One of our main design goals was to keep the Scratch (and by extension, Blockly) core codebases
as unmodified as possible, with modifications in the form of additional files when necessary,
as opposed to changes to core.
This is intended to streamline future upgrades by allowing them to be applied cleanly without
manually merging and accounting for conflicts.
As a result, we chose to introduce a layer of separation between the main CS First app
and Scratch for CS First by embedding Scratch for CS First in an iframe in the main app.
While this design makes upgrades more straightforward, it complicates direct interaction with Scratch
for CS First, such as saving student projects.
To work around this, we use the postMessage API to communicate between Scratch for CS
First and the main CS First app.
On load, both sides negotiate a handshake, and then use the postMessage channel to communicate.
Communication is bidirectional, and messages may optionally include a data payload.
Scratch for CS First has enabled deeper integration of the instructional content and the programming
environment than we've had in the past, where students would traditionally watch videos
and read instructional content in one tab and work on their project in another.
We're now able to bring the instructional content directly into the programming environment,
simplifying the workflow for students and removing a layer of abstraction.
We've recently introduced highlights, where instructional content is able to call out
regions and UI elements in Scratch for CS First.
When students click special links, a dynamic animated line emerges and guides them to the
block, sprite, category or other UI element being referenced.
This operates over the same postMessage bridge discussed earlier; the host CS First app messages
Scratch for CS First asking for the bounds of a particular element, then animates the
highlight to the returned coordinates.
We're also investigating adaptive highlights; for example, if a block is to be highlighted,
but the student is on the Sounds tab, we can infer that they first need to click the code
tab, then the category the block belongs to, scroll in the toolbox until the block is visible,
and then drag it out.
Scratch for CS First and CS First will mediate this interaction through sending Blockly/Scratch
for CS First events over the postMessage bridge, allowing CS First to know when the student
has taken an action that unblocks the next step in the chain of highlights, and then
resend the request for coordinates to trigger the next highlight.
We've also taken advantage of Blockly's flexibility to make things easier for instructional content
authors.
It's often useful to show students an image of a block or block stack they're building
or need to interact with, but managing screenshots across hundreds of lessons is complex and
error-prone; images may be overly large or compressed, making changes is a multi-step
process, and screenshots are not very accessible.
We allow content authors to define blocks using a domain-specific language when they're
writing lessons, and dynamically render the corresponding blocks in an offscreen Blockly
workspace.
Since blocks in Blockly are scalable vector graphics, known as SVGs, we're able to return
the SVG corresponding to the blocks, and render a pixel-perfect, scalable representation of
the blocks inline in the lesson content, without any network requests.
To take this even further, we're planning to embed Blockly into our internal content
management system so that content authors can build the block stacks directly without
the intermediary domain-specific language.
I hope this overview of how Blockly is used in practice at Google has been useful and
given you ideas for your own products and integrations.
To sum up a few key takeaways,
Design for upgradability.
Blockly is constantly improving, and the more you avoid making changes to core and use APIs
for extensibility, the easier it will be to take advantage of new features as they become
available.
Keep separation of concerns in mind.
Blockly is flexible and easy to embed; if your app has lots of functionality outside
of the programming environment, taking steps to isolate it can keep your architecture cleaner.
Consider how Blockly can enhance your instructional design.
Rather than telling students, show them!
Code generation, block rendering, monitoring event streams and Blockly plugins can enable
educational features much deeper than a simple video or written instructions and power dynamic,
engaging experiences.
Thank you.