Improv: Teaching Programming at Scale via Live Coding - Philip Guo
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Improv: Teaching Programming at Scale via Live Coding
Charles H. Chen Philip J. Guo
UC San Diego UC San Diego
La Jolla, CA, USA La Jolla, CA, USA
hsc052@ucsd.edu pg@ucsd.edu
ABSTRACT • Programmers write code live on stage during industry con-
Computer programming instructors frequently perform live ference presentations, which are recorded to share with the
coding in settings ranging from MOOC lecture videos to on- wider professional community. They like doing live demos
line livestreams. However, there is little tool support for this to convey a greater sense of authenticity and realism [35].
mode of teaching, so presenters must now either screen-share
or use generic slideshow software. To overcome the limita- • Programmers in domains such as game development
tions of these formats, we propose that programming environ- livestream their coding sessions on sites such as Twitch.tv
ments should directly facilitate live coding for education. We and Livecoding.tv to educate their online fans [21, 31].
prototyped this idea by creating Improv, an IDE extension for Despite the prevalence of live coding for education, current
preparing and delivering code-based presentations informed programming environments (IDEs) provide no support for
by Mayer’s principles of multimedia learning. Improv lets this type of activity. Thus, presenters usually end up screen-
instructors synchronize blocks of code and output with slides sharing and recording their entire desktop displays. This
and create preset waypoints to guide their presentations. A setup is cumbersome since there are lots of extraneous on-
case study on 30 educational videos containing 28 hours of screen components that are not relevant to the code-related
live coding showed that Improv was versatile enough to repli- ideas that the presenter is trying to convey at each moment.
cate approximately 96% of the content within those videos. In Also, it can be awkward to switch contexts in the middle of
addition, a preliminary user study on four teaching assistants a live demo by moving and flipping between windows on the
showed that Improv was expressive enough to allow them to desktop. Finally, it is hard to present higher-level concepts
make their own custom presentations in a variety of styles and such as topic outlines or algorithm descriptions by sharing
improvise by live coding in response to simulated audience only the contents of one’s code development environment.
questions. Users mentioned that Improv lowered cognitive
load by minimizing context switching and made it easier to An alternative format is for the presenter to copy-and-paste
fix errors on-the-fly than using slide-based presentations. all of their relevant code and output snippets into pre-made
PowerPoint slides. This format has the advantage of greater
INTRODUCTION structure and predictability. However, slide presentations can
A popular way to teach computer programming, both online appear stilted, inauthentic, and not in sync with real working
and in-person, is for the instructor to write snippets of code, code. Also, presenters cannot as easily improvise in response
run it, and then explain what their code does. By livestream- to audience questions.
ing or recording these performances, instructors can easily
To overcome the limitations of these existing presentation
share technical insights with thousands of viewers on learning
formats, we propose that programming environments (IDEs)
at scale platforms such as MOOCs, YouTube, and webinars.
should directly facilitate teaching via live coding. To proto-
This sort of live coding now takes place in diverse settings:
type this idea, we developed a system called Improv that helps
• Instructors write code live in front of their classrooms. instructors prepare and deliver code-based presentations en-
Computing education researchers recommend this as a best tirely from within their IDE. Its design was informed by our
practice since students can see their instructors’ thought formative studies and by Mayer’s principles of multimedia
processes, watch how mistakes are made and corrected, learning [25] from educational psychology. Figure 1 shows
and ask clarifying questions at each step [18, 27, 30, 35]. an example usage scenario for Improv:
• Similarly, instructors of online courses broadcast their live 1. The instructor writes and tests their code in any language
programming in webinars (“web seminars”). They also normally within the Atom IDE [2]. Improv extends Atom
record these sessions as videos for MOOCs and YouTube. with shortcuts that allow them to select any piece of code
Permission to make digital or hard copies of all or part of this work for personal or or terminal output in order to embed a live synced view of
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation that snippet into PowerPoint-style slides.
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or 2. Improv also extends Atom with an embedded slide presen-
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org. tation editor to drag-and-drop components into each slide.
L@S ’19, June 24–25, 2019, Chicago, IL, USA Supported components include: live code and output selec-
© 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM. tions from their IDE, text annotations, images, and iframe-
ISBN 978-1-4503-6804-9/19/06. . . $15.00 embedded contents from any webpage.
DOI: https://doi.org/10.1145/3330430.3333627
Figure 1: Improv augments the Atom IDE with UI affordances for preparing and delivering live coding presentations. The screenshots above show the
Atom IDE (left) and the slide viewer that the audience sees (right). Figure 3 shows Improv’s slide editor, and Figure 4 shows its code waypoints feature.
3. The instructor plans their live demo by creating optional This paper’s contributions to Learning at Scale are:
code waypoints and subgoal labels [14] for what code they
plan to write at each step. These serve as scaffolding during • A formative study of 20 educational videos to characterize
the presentation so that they can remain on course and so the diverse settings in which people perform live coding.
that the audience also knows what to expect at each step. • The idea that existing IDEs should add integrated support
for teaching programming via live coding.
4. When the instructor presents live, the audience always sees • A prototype of this idea in the Improv system. Improv in-
a fullscreen view of the slides instead of the entire com- troduces new UI affordances, informed by Mayer’s princi-
puter desktop (right part of Figure 1). As they write and ples of multimedia learning [25], that help instructors pre-
run code within Atom, their audience sees the embedded pare and deliver code-based presentations within their IDE.
code and output snippets update in real time on slides. We evaluated Improv with a case study on 30 videos and a
5. If they need to improvise in response to audience questions, preliminary user study on four teaching assistants.
they can edit code and slides on-the-fly in the middle of a
RELATED WORK
talk, and the audience sees all updates in real time. They
Researchers have mostly studied live coding in educational
can also snapshot their code so that they can quickly restore
it and get back on track after they are done improvising. settings [30]. As a pedagogical best practice they recommend
having an instructor write and explain code live in the class-
Instructors can use Improv either in a traditional in-person room or on video. Benefits include: making the instructor’s
lecture setting or in a learning at scale setting by livestream- step-by-step thought processes explicit [18, 27], enabling in-
ing or video-recording their hybrid code+slide presentations. structors to respond to “what-if?” questions from students by
Since it is web-based, remote viewers can connect to the editing their code on-the-fly [35], forcing instructors to incre-
Improv server to see the instructor’s live demonstration and mentally build up code and narrate aloud rather than show-
copy-paste code snippets into their own IDEs to follow along. ing large blocks of code at once [35], revealing sources of
common coding mistakes [18], making the instructor more
To evaluate the versatility and expressiveness of Improv, we relatable since students can see that they make mistakes as
ran a pair of complementary studies. We first performed a well [12], and holding students’ attention better since live
case study on 30 videos containing 28 collective hours of live coding is more dynamic than static PowerPoint slides [32].
coding presentations in settings ranging from university lec-
tures to online livestreams. We found that Improv was versa- Live coding is currently done by sharing the presenter’s
tile enough to be used to present approximately 96% of the screen with their audience (via a projector or online video
content within those videos. We then performed a prelim- stream) as they write and run code in text editors, termi-
inary user study by letting four first-time users prepare and nals, IDEs, or, more recently, computational notebooks (e.g.,
deliver 10-minute coding tutorial presentations using Improv. Jupyter [22], Codestrates [29]). Live streamers sometimes
We found that Improv was expressive enough to allow them use video mixing software such as OBS [6] to broadcast only
to create their own custom presentations in a variety of styles selected parts of their monitors, manage multi-monitor se-
and improvise by live coding in response to simulated au- tups, and display custom banners on their streams [21]. Since
dience questions. Users said that Improv lowered cognitive computational notebooks mix narrative text and code, some
load by minimizing context switching and made it easier to presenters manually scroll through them as a way of narrating
fix errors and improvise than using slide-based presentations. their code-based live demos. Users have restyled the CSS of
Jupyter notebooks to make them look more like PowerPoint URL Video Title (abbreviated) Language Features
slides [11]. Similar restylings can theoretically be done on University Classroom Lectures
Codestrates notebooks [29] as well. IDEs such as Cloud9 [3], xhgYsn Harvard CS50: Web Development Tech HTML/CSS E,S,T,W
Visual Studio [8], CodePilot [33], and Codechella [20] sup- BjHrZA Haverford College CMSC245: Pointers C++ E,S,T
port real-time multi-user code editing akin to Google Docs; Code-Based Conference Presentations
this feature can be used as a form of “IDE screensharing” 17h8Be Tricky JS Interview Questions JS S
XSx3eS Creating Electronic Dance Music JS, Node.js E,S
when giving talks. However, none of these tools were de- itJTjb Python And The Blockchain Python J,S
signed with structured presentation planning and delivery as M7cL5W Web programming from the beginning Python E,Q,T,W
their use case. In contrast, Improv integrates a slide-based KJAAaX Introduction to Statistical Modeling Python J,Q,T,W
presentation system and live coding environment into a pro- GbSTWy Time Series Analysis Python J,Q,S
o9ySGS PLOTCON 2016: Dash: Shiny for Python Python I,Q,W
grammer’s workflow within an IDE. The next section (For-
F9Jwv9 What Does It Take To Be An Expert? Python E,Q,T,W
mative Study and Design Goals) will highlight limitations of
current systems and how they inspired the design of Improv. Coding Livestreams on https://twitch.tv
jEjRkp Advice for Writing Small Programs in C C I,Q,S,T
More broadly, Improv contributes to the long lineage of HCI F6sBGj Private Data & Getters/Setters (Epic rant!) C++ E,Q
research in presentation systems by being the first, to our E8RkKu Building a Website - Live Coding w/ Jesse HTML/CSS E,W
knowledge, to be designed specifically for live coding pre- Coding Screencast Tutorial Videos
sentations. One major class of work here extends Microsoft 5irDUF Learn PHP in 15 minutes PHP E,S,W
PowerPoint: TurningPoint [28] implements six narrative tem- b1pKf3 Ruby Essentials for Beginners Ruby E,T
plates derived from guides of best practices centered on story- fYtjsB C# programming tutorial - Step by Step C# I,S
5sLQ5V Frequency Analysis with FFT JS, p5.js E,Q,W
telling techniques; users fill in the templates, and the system
QJQiKM Tensorflow for Seq2seq Models Python J
automatically generates starter slides. StyleSnap and Flash- KGx9V6 MongoDB Quickstart with PyCharm Python I,Q,S,W
Format help authors edit a large collection of PowerPoint WpTnuY Python Tutorial for Beginners #1 - Variables Python J,S
slides to maintain consistent visual style across similar ele-
Table 1: Corpus of live coding videos for our formative study. URLs
ments [16]. HyperSlides [17] helps authors plan hierarchi- should be prepended with https://goo.gl/. Feature abbreviations:
cal and non-linear navigation paths using a markup language. E=editor (e.g., Emacs, Vim), I=IDE, J=Jupyter notebook, Q=questions
In contrast to slide-based presentation systems, tools such as from audience, S=slide presentation, T=terminal, W=web browser
Pad++ [13], CounterPoint [19], and Fly [23] use a canvas
metaphor where presenters lay out elements in arbitrary loca- browser tabs, Figure 2e shows 29 browser tabs and 7 source
tions on a zoomable plane. However, all of the above systems code tabs in the IDE, and Figure 2f shows 7 browser tabs
are meant for general-purpose presentations, whereas Improv and 4 terminal app tabs. This complexity made it hard for
is specialized for code-related demos that mix live program- them to find specific windows on-demand, and they some-
ming and traditional slides. Improv improves upon general- times lost their place when navigating between windows. In
purpose presentation systems by adding novel interactions for contrast, those who projected full-screen slideshows did not
interfacing with a programmer’s workflow within an IDE. worry about context switching. However, slideshows lack the
dynamism of live coding performances.
FORMATIVE STUDY AND DESIGN GOALS
To understand how educators currently perform live coding Slides + live coding: Presenters often used pre-made slides
and to inform the design of Improv, we ran a formative study to convey higher-level concepts and then performed live cod-
by watching 20 programming videos (Table 1). Although no ing to demonstrate those concepts in practice. As Figure 2b
small sample can be universally representative, we strove for shows, some slides interspersed (non-runnable) code with
diversity in venues, modalities, and programming languages; bullet-point descriptions of their properties. After explain-
Figure 2 shows selected screenshots from these videos. These ing the code snippets on those slides, presenters then had
code-based presentations were recorded in university lecture to context-switch over to their text editor or IDE to edit a
halls, at software industry conferences, from livestreams on runnable version of that code in a live demo. If they want to
Twitch.tv, and from screencast tutorials on YouTube. Here update their presentations, they would need to keep both the
are our most salient observations from watching these videos: within-slides and within-IDE versions of their code in sync.
Context switching and visual noise: In Table 1, the “Fea- Highlighting code and outputs: While live coding, presen-
tures” column shows that most presentations featured more ters often selected text ranges in the editor to highlight a piece
than one medium (e.g., IDE, web browser, and slides). Pre- of relevant code as they explained its purpose (Figure 2d).
senters frequently switched between app windows; even They also switched to terminal windows to show textual out-
when the web browser was the active window (e.g., Fig- put for command-line-based programs, or a browser to show
ure 2a), they often switched between browser tabs. Some ar- visual output for web applications and interactive data vi-
ranged their windows in split-screen views (Figure 2c and e) sualizations. Some presenters used Jupyter notebooks to
while others left their desktops messy with overlapping win- show both code and output together (Figure 2a); they scrolled
dows and visual noise in taskbar and dock icons (Figure 2f). through the notebooks to highlight relevant parts.
Presenters usually opened all relevant windows and applica- Typos, commented-out code blocks, and copy-and-paste:
tion tabs before their talk began and flipped through them One big risk of live coding is that the presenter may make
during their talk. For instance, Figure 2a shows 8 open web mistakes. To reduce this risk, some presenters placed pre-
(a) Live coding in Jupyter notebook (URL: QJQiKM) (b) Slides with non-runnable code (URL: 17h8Be) (c) Web browser & editor split-screen (URL: F9Jwv9)
(d) Pointing to text editor in lecture (URL: xhgYsn) (e) Web app and IDE split-screen (URL: o9ySGS) (f) Many tabs & overlapped windows (URL: KJAAaX)
Figure 2: Screenshots from videos in Table 1 that show the diversity of modalities in live coding presentations. (Prepend https://goo.gl/ to URLs.)
made commented-out blocks of code to use as references Improv contains a set of novel interaction techniques for ex-
while they were live coding. Others copied-and-pasted snip- tracting code, creating and presenting slides, and adding in-
pets from auxiliary files into their code to avoid manually typ- structional scaffolding via code waypoints and subgoal labels.
ing everything from scratch. However, doing so detracts from
the authenticity of a fully-live performance. Ideally a presen- Extracting Code Blocks and Terminal Outputs from Atom
tation system would let presenters write code live and provide A programmer starts using Improv by creating a code project
a safety net to fall back on in case they made mistakes. in any language within the Atom IDE and testing to make sure
their code works as intended. Then they select blocks of code
Improvising in response to live questions: One major benefit
from their source files to include in their presentation slides.
of live coding is the ability to improvise in response to ques-
tions (the “Q” feature in Table 1). The audience asked ques- When the user selects a piece of text in either a code edi-
tions verbally during class lectures and conference talks and tor buffer or a terminal pane within Atom (which shows live-
via text chat in Twitch.tv livestreams. The presenter would updated contents of a shell, REPL, or compiler output), they
modify their code and re-run it to demonstrate their answers. can use a keyboard shortcut to extract that selection into a
Afterward they need to remember what they were working on code block. They can also select the entire file to extract as
before the question and restore their original code. a single block. (We call this a code block for simplicity, al-
though the user can extract any part of any Atom text buffer.)
Based on both these firsthand observations and by consulting
Mayer’s principles of multimedia learning [25], we developed Each selection gets colored in light blue within Atom (left
the following design goals for our Improv system: half of Figure 1). When the user makes later edits within its
range, the highlighted area will grow or shrink accordingly.
• D1: Minimize context switching and visual noise to help
These ranges get properly preserved even if new text is in-
both the presenter and audience focus better
serted above or below the selections. If the user erases every-
• D2: Integrate presentation slides with live runnable code thing within the selection (or its enclosing file gets deleted),
• D3: Support highlighting of code and outputs within slides then its corresponding code block gets deleted too. Users can
select and extract any number of code blocks across any files
• D4: Minimize the risk of errors while live coding in Atom. Each block is put into a storage bin in the presenta-
• D5: Enable improvising and quickly restoring prior context tion editor (Figure 3d), which can be dragged onto slides.
IMPROV SYSTEM DESIGN AND IMPLEMENTATION Slide Presentation Editor
Improv integrates into a programmer’s existing workflow Improv augments Atom with a simple slide presentation edi-
within an IDE so they can minimize context switching (De- tor situated in a new tab within the IDE. Figure 3 shows the
sign Goal D1). It is implemented with standard web technolo- UI of the slide presentation editor, which mimics a simplified
gies as an add-on for Atom, an extensible IDE [2]. Improv’s version of PowerPoint or Keynote. The user can create, re-
slide viewer uses Reveal.js [7] to display web-based slides order, and delete slides. Within each slide, they can add text
and Meteor.js [4] to perform real-time syncing. and images with direct manipulation. We implemented only
Figure 3: Improv’s slide editor is a pane within the Atom IDE. Here it shows two code blocks (a & b) and a terminal output block (c) that were extracted
from Atom in Figure 1. d) Extracted blocks are first put in a storage bin. The presenter can drag-and-drop these blocks, webpage embeds, and other
elements onto slides; they can also add/remove/reorder slides. The slide viewer that the audience sees (right of Figure 1) is synchronized with this editor.
basic slide editor functionality and did not replicate more ad-
vanced features such as animated transitions or style guides.
Improv’s editor supports two novel types of slide elements
specialized for our use case of live coding performances: This presenter has 29 web browser tabs open (left half) and
Code block elements: All code blocks extracted from Atom 7 source code tabs open in their IDE (right half), which
appear in a storage bin area at the right of the slide editor they had to juggle throughout their talk. They had so many
(Figure 3d). The user can drag and drop these blocks onto open browser tabs that they could not even see the tab titles.
any slide just like how they can insert text and images. This Throughout the talk, they also had to constantly scroll to dif-
way, a single code block can appear on multiple slides. Code ferent parts of webpages and source code files to find the right
blocks in slides are synced in real time with their correspond- parts to discuss. If they had used Improv, they would have
ing selected regions in the IDE. Thus, when the user edits that been able to selectively embed the desired portions of web-
code, it will also update on the slide(s). When the user’s code pages and source code files into a series of slides with a logi-
runs and produces output, any embedded terminal blocks also cal ordering and accompanying slide titles for exposition.
update live (Figure 3c). This feature allows presenters to cre-
ate slides that mix text and runnable code (Design Goal D2).
Slide Viewer: Presentation Delivery and Live Coding
Even if the presenter does not want to perform live coding After the user creates a code-based presentation within Atom,
and simply wants to deliver a standard slideshow presenta- they can also deliver their presentation entirely within Atom.
tion, this live code block feature is still beneficial for two rea-
sons: 1) It avoids having to keep two copies of code in sync To do so, they first open a new web browser window and point
between the IDE and slides, 2) It helps ensure that code which it to a localhost URL for the slide viewer app. This viewer is
appears on slides actually compiles and runs, since it is real a webpage that synchronizes its contents in real time with the
working code that can be executed and tested within the IDE. currently-active slide displayed in Atom’s slide editor. Then
Otherwise it is easy for subtle typos and bugs to creep into they connect their laptop to a projector and move the slide
code-based slides, which causes learner frustration [26]. viewer window to the projected screen in full-screen mode.
This way, the presenter still sees their own Atom IDE (and
Webpage iframe elements: The editor also allows the user to everything else on their desktop) while the audience sees only
live-embed any webpage as an iframe into their slides. This is the viewer app on the projected screen. This minimizes visual
important because many of the live coding videos we watched noise (Design Goal D1) since the audience no longer sees the
featured presenters navigating through webpages such as API entire contents of the presenter’s desktop. It also conforms
documentation, data visualizations, and Jupyter notebooks. to Mayer’s coherence principle of multimedia learning [25],
The user can scroll to any portion of the webpage to start which posits that people learn better when extraneous visual
showing that part during the presentation, which is convenient elements are excluded from view to minimize distractions.
for long webpages such as API docs or Jupyter notebooks.
Alternatively, the presenter can host the slide viewer web app
These features give presenters both the organizational ben- on a public IP address. This way, audience members (either
efits of pre-made slides and the dynamism of live code and in the room or remotely on the internet) can connect to that IP
webpages. To demonstrate the utility of embedded code and to watch the presentation live from their own web browsers.
webpage elements, here is a zoomed-in view of the top part They can also copy-and-paste the code shown in the presen-
of the video in Figure 2e from our formative study corpus: tation to experiment with it locally in their own IDEs.
Since the contents of Improv’s slide editor are always in sync
with the slide viewer, there is no distinction between presen-
tation editing and delivery modes. The audience always sees
the currently-active slide in the editor. To deliver a presen-
tation, the presenter simply flips through their slides in se-
quence in the editor. If they want to create new slides or mod-
ify the contents of existing slides on-the-fly, the audience will
see those changes immediately. In addition, besides showing
traditional slideshows, Improv’s slide viewer also has support
for webpage iframes, code blocks, and live coding:
Presenting webpage iframe elements: Since webpages are
embedded as iframes, when the presenter scrolls through each Figure 4: Improv lets users define waypoints to serve as scaffolding for
live coding sessions. a) The code block that is projected on the current
iframe in the slide editor, Improv synchronizes its current slide is highlighted in yellow. b) Click to add its state as a new waypoint.
scroll position with the viewer app so that the audience sees c) See a preview of the next waypoint, and navigate to other waypoints.
that same scrolling happening. This way, the presenter can
walk through each page’s contents by scrolling and narrating. • To show how to build a web application or interactive visu-
The viewport sizes of the editor and viewer iframes are iden- alization, the presenter can create a slide with a code block
tical, so webpages render identically in both when scrolling. alongside a webpage iframe pointed to the web application
Presenting code block elements: Likewise, the presenter that is currently under development.
can scroll through code blocks in the slide editor, and the au- • To teach a classroom lesson on algorithms, the presenter
dience again sees a synchronized view. This is effective for can embed text and images of the relevant concepts along-
explaining pre-written static blocks of code, but what happens side a live code block that shows its implementation.
when the presenter wants to write code live? • To demonstrate how to use a particular API, the presenter
Live coding: To perform live coding anytime during a pre- can embed a webpage of the API docs next to a code block.
sentation, the presenter clicks a button atop an embedded One recommended way to organize slides is to have each slide
code block in the slide editor to jump to the portion of the hold one part of the overall live demo. This way, presen-
original source file in the Atom IDE where that code was ters can advance through all slides in sequence and perform
extracted from. They should now see that selection of code live coding on the appropriate parts of their codebase without
highlighted in yellow, which indicates that it is being pro- fumbling to look for the relevant source files or browser tabs.
jected on the active slide for the audience to view (Figure 4a).
They can edit that code normally within Atom, and all up- Code Waypoints and Subgoal Labels
dates will propagate live to the slide viewer app. In addition, It can be hard to write code live during a presentation with-
in the slide viewer that code block auto-scrolls so that its cur- out making mistakes, so the presenters in the formative study
rent cursor position is vertically centered. This ensures that videos we watched often resorted to copying and pasting pre-
currently-edited code is always visible to the audience. written blocks of code from other text buffers into their target
In our example, the contents of the code blocks labeled ‘a’ source files. Unfortunately, doing so detracts from the authen-
and ‘b’ in Figure 3 always remain in sync across the Atom ticity and natural flow of truly doing live coding. To preserve
code editor, slide presentation editor, and slide viewer. Simi- such authenticity while also guarding against errors (Design
larly, the terminal output block (Figure 3c) is also synced. Goal D4), Improv lets users define a set of code waypoints for
each code block (inspired by navigational waypoints [9]).
While the audience sees only what is on the slides, the pre-
senter can perform live coding within their IDE with full ac- After the user extracts a code block in the IDE by making a
cess to all of the programming assistance tools they are accus- text selection, they can optionally open an inline pane to add
tomed to. The presenter can also access other desktop apps, waypoints for that given block (Figure 4). Each waypoint is
API documentation, or speaker notes “behind the curtains” a manually-defined version of the code in that block. It is up
without the audience seeing or getting distracted by them. to the user to fill out the contents of each version, but one
heuristic is to have each version represent a new concept or
If the presenter highlights a selection of text as they are live step that is being incrementally built up within that block.
coding, that visual highlight will also appear on the slides for
the audience to view (Design Goal D3). This allows the pre- The user can also add a subgoal label to each waypoint,
senter to point out specific pieces of code or terminal output which is a textual annotation that describes the purpose (goal)
to explain it in detail. of what that waypoint aims to achieve. Subgoal labeling
is a pedagogical best practice whereby the instructor adds a
Improv gives instructors a great deal of flexibility in terms of higher-level conceptual description for each group of steps in
how to structure their live coding sessions. For instance: a tutorial; it has been shown to help improve learner compre-
• To demonstrate how a terminal-based program works (e.g., hension in a variety of STEM domains [14, 24, 34].
a Python or C program), the presenter can create a slide that Live coding with waypoints: If waypoints are set on a given
contains a code block alongside a terminal output block. code block, then when the presenter is live coding in there,
they see not only their current code but also the waypoint’s Procedure: We used the 20 videos in our formative study
code in a separate pane (Figure 4c). This pane serves as a corpus (Table 1). To guard against “overfitting” on this ini-
“teleprompter” that gives them a visual indicator of what code tial corpus, we found 10 additional videos using a similar
they ought to be writing at the moment to reach that waypoint. methodology but after finishing the implementation of Im-
It is also similar to how DemoWiz [15] cues the presenter by prov. These represent a diverse selection of code-based pre-
showing previews of upcoming events on screencast videos. sentations that people have delivered to a range of audiences.
We watched each video in detail and hand-classified the time
In addition, the waypoint’s subgoal label is always displayed durations within each one based on what is being displayed on
above the code block in the slide viewer app so that the au- the screen at those times. Then we estimated the proportion
dience can see the purpose of the current step that is be- of time that Improv could plausibly be used as a replacement
ing demonstrated by the presenter. This feature abides by
for the presentation media that the speaker actually used.
Mayer’s segmenting and signaling principles of multimedia
learning [25], which posits that people learn better when pre- Findings: Figure 5 summarizes our findings. The entire du-
sentations are divided into logical segments with cues that ration of each video is a horizontal bar, and the labeled por-
signal what to expect from each segment. tions represent time ranges when the presenter was working
within a particular app (e.g., terminal, IDE, slides). The red
Once the presenter has written enough code in the current portions represent time ranges where Improv cannot be used
block so that it exactly matches the expected contents of the
to emulate what the presenter was doing at those times (see
current waypoint, Improv automatically moves onto display-
details below). The red portions account for 4% of the total
ing the next waypoint. The presenter can always deviate from
time across all 30 videos, which means that Improv can serve
the waypoint if they want to improvise or format their code in as a plausible replacement for presenting approximately 96%
a different way. In those cases, their end state will not be an of the content in our 28-hour corpus of 30 live coding videos.
exact string match, so they can manually move onto the next
(or previous) waypoint with navigation controls. Presenters could have used Improv to create nearly all parts
of these presentations, based on the apps being used in them:
If the presenter gets stuck or lost while live coding, they can
click the “next waypoint” button in the waypoint pane to copy • Text Editor (3% of total running time across all 30 videos):
the contents of the current waypoint into their code block and With Improv, they could have extracted a code block to
move onto the next waypoint. Although this action breaks the place on slides and performed live coding within Atom.
authenticity of live coding, it is convenient for getting the pre-
• IDE (6% of total video time): Same as text editor. Note that
senter out of a jam and ensuring that they still have working
presenters did not use advanced IDE features; they used
code (assuming that their pre-written waypoint code works
IDEs only as elaborate text editors for live coding.
and that they have not broken any code outside of that block).
• Terminal (6%): Extract a terminal output block to slides.
For example, Figure 4 shows the waypoint pane in Atom.
As the presenter is in the middle of writing the body of the • Web Browser (9%): Embed a webpage iframe into slides.
deactivate() method in the yellow code block, they can • Jupyter Notebooks (20%): Same as web browser. (Note
see the next waypoint they are supposed to reach in order to we put Jupyter into its own category since many presenters
complete the current segment of their demo (Figure 4c). used it as a web-based live programming environment.)
Impromptu waypoints: Finally, when the presenter gets a • Slide Presentation (13%): Use Improv’s slide editor.
question from the audience or otherwise wants to improvise,
they can click the “Add as Waypoint” button on a code block • Code on Slides (3%): These are slides that primarily show-
to save a snapshot of its current contents as a new waypoint. case snippets of code. With Improv, they can extract code
This way, they can freely modify their code to address the blocks so that those snippets update live on their slides.
given question and quickly restore their original code after- Presenters also concurrently used two apps in either a split-
ward to return to their main presentation (Design Goal D5). screen view or by rapidly flipping back and forth: text editor
+ terminal (11% of total time in all videos), text editor + web
EVALUATION browser (12%), IDE + terminal (9%), IDE + web browser
To assess Improv’s versatility and expressiveness, we ran a (4%). Improv can handle all of these cases by placing mul-
pair of studies to investigate the following questions: tiple components on a single slide: either a code block and a
terminal output block, or a code block and a webpage iframe.
• Is Improv versatile enough to be used to prepare and de-
liver a diverse variety of realistic code-based presentations? Improv could not plausibly emulate what presenters featured
during 4% of the total time in these 30 videos (4.7% of total
• Is Improv expressive enough to let first-time users create time in the original 20 formative study videos and 2.3% in the
presentations of their own original design? additional 10 we picked). During those times, presenters used
GUI applications, sketching, or physical demonstrations. The
most common modality was the presenter demonstrating spe-
Case Study of Coding Presentation Videos cific features of GUI applications such as the Ableton [1] mu-
To assess the versatility of Improv, we performed a case study sic production software, the Wireshark [10] network analyzer,
on 30 programming tutorial videos from YouTube. or the Windows process manager for showing memory usage
Figure 5: Presentation formats in 30 programming videos: 20 were from Table 1; YouTube IDs are next to 10 new videos. Red = Improv cannot emulate.
patterns. Three presenters made digital sketches over their who interrupted with questions to simulate an audience. Fi-
screens. Finally, one presenter projected an Oculus Rift head- nally, we concluded the session by asking them to reflect on
set [5] display for a virtual reality live coding demonstration. the advantages and disadvantages of using Improv when com-
In the future, we could extend Improv to embed a live view pared to presentation tools that they had previously used.
of the presenter’s computer desktop or external video feeds in
order to support these modalities. Findings: All four participants were able to use Improv to
successfully prepare and deliver a presentation of their own
Study Limitations: This is an informal case study on a hand- original design. These varied widely in subject matter pre-
picked video corpus. Even though we strove for diversity in sented, Improv features used, and presentation styles:
presentation formats and selected 10 additional videos after
• P1 taught basic JavaScript by demonstrating a simple
finishing Improv’s implementation, we cannot be sure that
these are representative of all code-based presentations. Also, command-line calculator with Node.js. When preparing
there is no guarantee that the presenters would actually prefer their talk, they wrote pieces of code in Atom and included
replacing their current setups with Improv, or how the audi- them onto three slides along with explanatory text. They
ence would react to seeing Improv versions of these talks. did not originally intend to perform live coding. However,
as they started presenting their slides and the facilitator in-
terrupted with questions, they used the code waypoints fea-
Preliminary User Study with Teaching Assistants ture to create impromptu waypoints so that they could per-
Our case study demonstrated the potential versatility of Im- form live coding to address questions. Then they returned
prov across a variety of presentation formats, but we also to prior waypoints to resume their talk. They also impro-
wanted to see how expressive it is when put into the hands of vised by embedding a terminal onto a slide and live coding
first-time users. To do so, we performed a preliminary study from the Node.js REPL to show additional concepts.
with 4 computer science teaching assistants at our university.
• P2 taught the concept of function calls using pseudocode.
Procedure: Each participant came to our lab to use Improv Their two slides consisted of images and pseudocode. De-
individually for 1 hour. We first gave them a 10-minute tuto- spite not performing any live coding, they still found it use-
rial of Improv’s basic features and then instructed them spend ful to organize pseudocode in text files within Atom and to
most of the hour using it to create a five to ten-minute code- selectively extract them onto slides. When the facilitator
related presentation of the sort that they would normally make pointed out a possible bug in the pseudocode, they were
for their courses. When they finished creating the presenta- able to fix it right away by editing that section in the text
tion, we had them use Improv to deliver it to the facilitator, file and seeing the update instantly appear on the slides.
• P3 taught array operations in Python. They created three In sum, first-time users found Improv expressive enough to
Python source code files in Atom, one for each concept: use for preparing simple teaching presentations that mixed
indexing, slicing, and element skipping. They tested their both code and expository content. All four participants re-
code separately in each file and then extracted each one to ported being interested in using Improv in their own teaching.
place on its own slide with a corresponding title. They also
placed a terminal output block at the bottom of all slides. Study Limitations: We conducted an informal first-use study
During their talk, they moved between the three slides and without a control group. Although participants reflected on
performed live coding in Atom; when their Python code the experience of using Improv versus tools they previously
executed, it showed up in the terminal block on each slide. used, we did not perform a formal comparison against exist-
ing tools. Also, due to the short study duration, participants
• P4 taught Python variables and print statements. They took used Improv to deliver at most a 10-minute presentation, so
the most dynamic approach out of all four by using only we were not able to assess its scalability for preparing, say,
one slide and having it serve as a fullscreen canvas. They hour-long lectures with dozens of slides. Finally, the facilita-
put a code block, terminal output, and webpage iframe into tor served as a simulated audience, but ideally Improv would
that single slide. While preparing the talk, they used the be evaluated in a class setting to gauge real student reactions.
iframe to look up Python reference documentation rather
than switching to an external web browser since they could
see the reference in the same context as their code. While DISCUSSION AND CONCLUSION
delivering the talk, they live coded from within Atom. Improv explores the design space of educational presentation
tools in between slide-based software (organized but static)
Improv supported both the more static slides-based presenta- and desktop screensharing (authentic but messy). It melds
tions (P1 and P2) and the more dynamic live coding sessions the organizational benefits of slide-based presentations with
(P3 and P4). P1 was even able to switch from slides to live the authenticity and improvisational flexibility of live cod-
coding on-demand when the facilitator asked questions. ing. Improv’s code-based slide format gives presenters the
During post-study debriefing interviews, participants men- ability to organize their content in accordance with pedagog-
tioned the following advantages of Improv as compared to ical best practices such as Mayer’s principles of multimedia
existing presentation tools that they had previously used: learning [25]: They can display code in large fonts, eliminate
extraneous visual noise from desktop apps, and supplement
• Lower cognitive load when live coding, since they did not code with textual annotations, images, and webpage embeds.
need to repeatedly switch back and forth between different
apps such as IDEs, terminals, browsers, and PowerPoint. One main limitation, though, is that there are times when pre-
senters want to project their entire computer desktop for the
• Relatively easy to fix errors on the fly by adjusting code audience to view instead of presenting slides. This could arise
or slide content directly from within Atom and having the because they want to demonstrate how to interact with a set
audience see those changes immediately. of complex GUI applications. Improv is not well-suited for
• P1, P3, and P4 felt that the clearest benefit of Improv was those use cases since, by design, it shows only selected code
the ability to write and run code in a real IDE but to have blocks within a traditional slide presentation. In the future,
the audience see that code on an organized set of slides. we could extend it with a screensharing plug-in that allows it
• P1 found waypoints useful for improvising. P3 manually to embed portions of the presenter’s desktop into slides.
emulated waypoints by having an auxiliary notes file where Currently instructors who want to teach programming to a
they stored code snippets that they copied into their presen- large audience must rely on ad-hoc setups involving screen
tation code. When we reminded them about the waypoints sharing, PowerPoint slides, and flipping between disparate
feature at the end, they agreed it would have been useful desktop applications. Our Improv system takes steps toward
but was not sufficiently familiar with it as a first-time user. making this form of technical pedagogy both more organized
• P4 appreciated the flexibility of Improv’s slide format com- and more fluid. From an educational technology perspective,
pared to traditional presentation tools: “I think of these Improv’s main contribution to learning at scale is to bring
slides more as workspaces. [...] You normally see a slide Mayer’s principles of multimedia learning [25] into the pop-
as very specific and like a state of mind that is progressing. ular domain of live coding presentations. We hope that by
But here the slide itself is dynamic. More like a workspace deploying this system in MOOCs and other online learning
where you can drop code and dynamic stuff is happening.” platforms in the future, students will be able to learn better by
watching instructors more fluently combine live coding with
Participants also pointed out their perceived limitations of Im-
slide-based presentations. They can either connect to the Im-
prov. Most notably, they mentioned higher cognitive load
prov slide viewer web app for a live broadcast or watch pre-
during presentation planning, since they had to develop a
recorded videos of these hybrid code and slide presentations.
mental model of how three separate components synced up
with one another: their own code within Atom, the slide edi-
tor, and the slide viewer. Also, they were surprised that they ACKNOWLEDGMENTS
could not edit code on the slides to fix minor issues but in- Thanks to Darren Chan, Parmit Chilana, Jonathan Edwards,
stead had to edit within the corresponding source code file in Ailie Fraser, Andrew Hild, Kandarp Khandwala, Sean Kross
Atom. To support this, we can implement bidirectional sync- (for Figure 5!), Jeremy Lai, Christine Lee, and Alok Mysore
ing between Atom’s code editor and Improv’s slide editor. for their feedback on the research that led to this paper.REFERENCES 21. Suz Hinton. 2017. Lessons from my first year of live coding on Twitch.
1. 2018. Ableton: Music production with Live and Push. https://medium.freecodecamp.org/
https://www.ableton.com/en/. (2018). lessons-from-my-first-year-of-live-coding-
2. 2018. Atom IDE. https://ide.atom.io/. (2018). on-twitch-41a32e2f41c1. (2017).
3. 2018. AWS Cloud9: A cloud IDE for writing, running, and debugging 22. Thomas Kluyver, Benjamin Ragan-Kelley, Fernando Pérez, Brian
code. https://aws.amazon.com/cloud9/?origin=c9io. Granger, Matthias Bussonnier, Jonathan Frederic, Kyle Kelley, Jessica
(2018). Hamrick, Jason Grout, Sylvain Corlay, Paul Ivanov, Damián Avila,
Safia Abdalla, and Carol Willing. 2016. Jupyter Notebooks – a
4. 2018. Meteor: Build Apps with JavaScript. publishing format for reproducible computational workflows. In
https://www.meteor.com/. (2018). Positioning and Power in Academic Publishing: Players, Agents and
5. 2018. Oculus Rift - Oculus. https://www.oculus.com/rift/. Agendas, F. Loizides and B. Schmidt (Eds.). IOS Press, 87 – 90.
(2018). 23. Leonhard Lichtschlag, Thorsten Karrer, and Jan Borchers. 2009. Fly: A
6. 2018. Open Broadcaster Software. https://obsproject.com/. Tool to Author Planar Presentations. In Proceedings of the SIGCHI
(2018). Conference on Human Factors in Computing Systems (CHI ’09). ACM,
7. 2018. reveal.js - The HTML Presentation Framework. New York, NY, USA, 547–556.
https://revealjs.com/. (2018). 24. Lauren E. Margulieux, Mark Guzdial, and Richard Catrambone. 2012.
8. 2018. Visual Studio Live Share: Real-time collaborative development. Subgoal-labeled Instructional Material Improves Performance and
https://code.visualstudio.com/ Transfer in Learning to Develop Mobile Applications. In Proceedings
visual-studio-live-share. (2018). of the Ninth Annual International Conference on International
Computing Education Research (ICER ’12). ACM, New York, NY,
9. 2018. Waypoint (Wikipedia). USA, 71–78.
https://en.wikipedia.org/wiki/Waypoint. (2018).
25. Richard E. Mayer. 2009. Multimedia Learning (2nd ed.). Cambridge
10. 2018. Wireshark - Go Deep. https://www.wireshark.org/.
University Press, New York, NY, USA.
(2018).
26. Alok Mysore and Philip J. Guo. 2017. Torta: Generating Mixed-Media
11. Damian Avila. 2017. RISE: Reveal.js - Jupyter/IPython Slideshow
GUI and Command-Line App Tutorials Using Operating-System-Wide
Extension.
Activity Tracing. In Proceedings of the 30th Annual ACM Symposium
https://damianavila.github.io/RISE/index.html.
on User Interface Software and Technology (UIST ’17). ACM, New
(2017).
York, NY, USA, 703–714.
12. Lecia J. Barker, Kathy Garvin-Doxas, and Eric Roberts. 2005. What
Can Computer Science Learn from a Fine Arts Approach to Teaching?. 27. John Paxton. 2002. Live Programming As a Lecture Technique. J.
In Proceedings of the 36th SIGCSE Technical Symposium on Computer Comput. Sci. Coll. 18, 2 (Dec. 2002), 51–56.
Science Education (SIGCSE ’05). ACM, New York, NY, USA, 28. Larissa Pschetz, Koji Yatani, and Darren Edge. 2014. TurningPoint:
421–425. Narrative-driven Presentation Planning. In Proceedings of the SIGCHI
13. Benjamin B. Bederson and James D. Hollan. 1994. Pad++: A Zooming Conference on Human Factors in Computing Systems (CHI ’14). ACM,
Graphical Interface for Exploring Alternate Interface Physics. In New York, NY, USA, 1591–1594.
Proceedings of the 7th Annual ACM Symposium on User Interface 29. Roman Rädle, Midas Nouwens, Kristian Antonsen, James R. Eagan,
Software and Technology (UIST ’94). ACM, New York, NY, USA, and Clemens N. Klokmose. 2017. Codestrates: Literate Computing
17–26. with Webstrates. In Proceedings of the 30th Annual ACM Symposium
14. Richard Catrambone. 1998. The Subgoal Learning Model: Creating on User Interface Software and Technology (UIST ’17). ACM, New
Better Examples so That Students Can Solve Novel Problems. 127 (12 York, NY, USA, 715–725.
1998), 355–376. 30. Adalbert Gerald Soosai Raj, Jignesh M. Patel, Richard Halverson, and
15. Pei-Yu Chi, Bongshin Lee, and Steven M. Drucker. 2014. DemoWiz: Erica Rosenfeld Halverson. 2018. Role of Live-coding in Learning
Re-performing Software Demonstrations for a Live Presentation. In Introductory Programming. In Proceedings of the 18th Koli Calling
Proceedings of the SIGCHI Conference on Human Factors in International Conference on Computing Education Research (Koli
Computing Systems (CHI ’14). ACM, New York, NY, USA, Calling ’18). ACM, New York, NY, USA, Article 13, 8 pages.
1581–1590. 31. Scott Rosenberg. 2015. The Strange Appeal of Watching Coders Code.
16. Darren Edge, Sumit Gulwani, Natasa Milic-Frayling, Mohammad Backchannel: WIRED https://www.wired.com/2015/08/
Raza, Reza Adhitya Saputra, Chao Wang, and Koji Yatani. 2015. the-strange-appeal-of-watching-coders-code/.
Mixed-Initiative Approaches to Global Editing in Slideware. In (2015).
Proceedings of the 33rd Annual ACM Conference on Human Factors in 32. Marc J. Rubin. 2013. The Effectiveness of Live-coding to Teach
Computing Systems (CHI ’15). ACM, New York, NY, USA, Introductory Programming. In Proceeding of the 44th ACM Technical
3503–3512. Symposium on Computer Science Education (SIGCSE ’13). ACM, New
17. Darren Edge, Joan Savage, and Koji Yatani. 2013. HyperSlides: York, NY, USA, 651–656.
Dynamic Presentation Prototyping. In Proceedings of the SIGCHI
33. Jeremy Warner and Philip J. Guo. 2017. CodePilot: Scaffolding
Conference on Human Factors in Computing Systems (CHI ’13). ACM,
End-to-End Collaborative Software Development for Novice
New York, NY, USA, 671–680.
Programmers. In Proceedings of the 2017 CHI Conference on Human
18. Alessio Gaspar and Sarah Langevin. 2007. Restoring ”Coding with Factors in Computing Systems (CHI ’17). ACM, New York, NY, USA,
Intention” in Introductory Programming Courses. In Proceedings of the 1136–1141.
8th ACM SIGITE Conference on Information Technology Education
34. Sarah Weir, Juho Kim, Krzysztof Z. Gajos, and Robert C. Miller. 2015.
(SIGITE ’07). ACM, New York, NY, USA, 91–98.
Learnersourcing Subgoal Labels for How-to Videos. In Proceedings of
19. Lance Good and Benjamin B. Bederson. 2002. Zoomable User the 18th ACM Conference on Computer Supported Cooperative Work
Interfaces As a Medium for Slide Show Presentations. Information & Social Computing (CSCW ’15). ACM, New York, NY, USA,
Visualization 1, 1 (March 2002), 35–49. 405–416.
20. Philip J. Guo, Jeffery White, and Renan Zanelatto. 2015. Codechella: 35. Greg Wilson. 2018. How to Teach Programming (and Other Things):
Multi-user program visualizations for real-time tutoring and Live Coding.
collaborative learning. In Proceedings of the IEEE Symposium on http://third-bit.com/teaching/live.html. (2018).
Visual Languages and Human-Centric Computing (VL/HCC) (VL/HCC
’15). 79–87.You can also read
