Identifying Code Presentation Challenges Regarding the Preparation and Presentation Delivery of Programming Projects Hindering Productivity and Presentation Performance to Inform the Potential Development of a Web and Desktop SaaS Product for Software Developers

Problem Statement

Who

Who has the problem?

Target User Group

The following outlines the user profiles for software developers who showcase and prepare programming projects with the purpose of:

Creating educational and informative programming tutorials

• 7 out of 8 total participants recruited

Showcasing informational slide show presentation

• 0 out of 8 total participants recruited

Conducting a live programming demo

• 1 out of 8 total participants recruited

The ideal research study would total 24 participants per target user group.

What

What are the problems or key challenges?

Software developers face several key challenges when preparing and presenting code:

Code Build Order & Setup is Manually Intensive

Participants face a multitude of hurdles when trying to prepare their code for presentation. This challenge includes spending a large amount of time manually setting the build order of code using external note tools or code comments leading to disjointed and hard-to-read source code.

Presentation Notes And Code Readability Issues

The absence of dedicated presenter notes and features results in developers resorting to adding comments directly to the code. This practice makes the code harder to read, impacting the presenter's ability to navigate smoothly through the presented material. Some developers resort to using external tools for making scripts and annotating code.

Typing Errors and Bugs

Developers encounter errors and typos while typing and presenting code, disrupting the flow of their presentation and requiring time-consuming corrections in post-production. During the presentation process, developers mentioned having trouble with cognitively demanding tasks like typing and explaining their code leading to misspeaking and mistyping.

Testing, Building, And Running Code

Due to the complexity of software development, multiple developers expressed the need to test, build, and run their code on their preferred development environment using adequate tools for troubleshooting their code.

Lack of Presentation Tools

Due to a lack of presentation tools, developers resort to jerry-rigging their project presentation setup by manually splitting their layout into multiple screens requiring them to jump back and forth reading their notes and reference code leading to massive cognitive load and human errors.

Accessibility, UI Layout And Settings

Certain development tools lack accessibility features, negatively impacting the quality of code presentation. Due to this issue, developers have voiced their desire for comprehensive accessibility features and settings to enhance the legibility of their code across various devices. Additionally, maintaining a clean UI layout is crucial to avoid distracting the audience during code presentations.

Where

Where/When the problem is occurring?

These challenges occur primarily during two key phases:

Preparing Code and Notes for Presentation

Participants encounter difficulties when manually organizing their code and notes for presentation, leading to inefficiencies and increased preparation time.

Presenting Code

During the presentation, developers struggle with typos, distractions, and multitasking challenges, hindering the smooth delivery of their content and leading to spending more time on post-production editing out their mistakes.

Why

Why is it important to address the problem?

Addressing these challenges is crucial because:

Time Investment And Product Creation

Developers are currently spending excessive hours preparing their code and notes for presentation, impacting overall productivity and content creation.

Error Reduction

Typos and programming errors, stemming from the multitasking nature of explaining code, reading notes, and writing code simultaneously, need to be minimized to enhance the quality of presentations.

Efficiency in Presentation

Streamlining the code presentation process using autonomous systems will contribute to shorter presentation times, allowing developers to focus on delivering content rather than typing code.

• Presenting code in Keynote
• Writing Code like a Real Hacker (VS Code Macro Extension)
• Styling code snippets in Keynote
• What Makes a Good Conference Session or Keynote?
• Targeting Keynote’s Build Order Properties
• A couple of ways to highlight code syntax in Apple Keynote slides

Overview

With the evolution of the digital landscape and various platforms, more opportunities have emerged for learning and teaching software development. Whether it's a professor conducting a live coding lecture (e.g., Harvard CS50x taught by David Jay Malan), a content creator producing programming tutorials (e.g., Brian Voong), or a developer showcasing a tech demo at a software development conference (e.g., Google I/O), the potential for identifying and addressing issues related to software presentations has never been greater. The generative research aims to explore and understand the users, their needs, and behaviors to identify opportunities, define problems, and generate insights to explore the possibility of developing a SaaS product designed to target the pain points and inadequacies associated with preparing and presenting code presentations.

Problem Statement Summary

FYI: Problem statement is updated to reflect the most recent research data.

Per my research study, software developers face an array of diverse challenges that impact their productivity when preparing and presenting code. The following pain points are considered by the majority of participants to be manually intensive, error-prone, knowledge-dependent, and cognitively demanding tasks. These challenges include problems with preparing and organizing the build order of their code, typing code leading to errors, bugs, typos, and compiler warnings, note taking on code leading to poor code readability and the overall complexity of the source code and project resulting to creating less content due to the amount of work it takes to complete a project. These issues occur during code preparation, leading to investing a massive amount of time completing projects, and during coding presentations, hindering progress. Addressing these challenges is crucial to improving productivity, eliminating errors, and streamlining the presentation and preparation process, allowing developers to focus on content delivery rather than grappling with code and presentation-related hurdles.

Research Goals, Questions, Assumptions

Goals And General Broad Themes

Project Planning

• Gain insights into the code planning process and assess whether developers write code before planning their material.
• Understand the factors that influence the developer's decision-making when considering programming projects for presentation.
• Investigate whether the amount of source code influences developers' decisions in preparing their projects.

Code Setup

• Examine the steps and procedures developers undertake when configuring their code for presentation.
• Do developers organize the presentation content in a logical and coherent structure?

Notes

• Evaluate whether developers are writing notes for their projects, and if so, how and where these notes are documented.
• Understand the developer's note-taking process.
• What tools do developers use when taking notes?

Code Presentation

• Delve into user behavior and the dynamics of developers presenting their code.
• Pinpoint common challenges developers face during coding demonstrations.
• Comprehend the specific needs and expectations developers have regarding coding presentations and error handling.

Tooling

• Identify user preferences concerning code presentation tools, features, and functionalities that facilitate project preparation.
• Do participants use presentation tools like Keynote, PowerPoint, or any software equivalent tools?
• Have participants use any code-oriented tools like Animotion or Motion Canvas.
• Evaluate the participant's biggest frustrations with the tools they use.
• What do their current tools do well that help them present code?

Efficiency Metrics

• Assess the time spent by developers on setting up and organizing code.
• Quantify the time invested by developers in creating presenter notes.
• Measure the time developers allocate to presenting their code.
• Asses tasks that are:Manually IntensiveCognitively demandingError-proneKnowledge dependent

Ideations

• Analyze the ideal solutions a participant suggests for solving their code presentation hurdles.

Competitive Analysis

• Explore existing solutions within the market and figure out their strengths and weaknesses.
• Identify features or approaches employed by competitors that address the identified challenges.
• Do presentation tools in the code presentation market address the concerns and expectations of their targeted demographic?

Assumptions, Opinions And Questions

All questions and assumptions are listed and addressed in the knowledge quadrant. Part of the main goal of the research is to answer the questions, opinions, and assumptions listed in the knowledge quadrant.

Scope

Team & Stakeholders

User Experience Researcher

• Ricky. B

Budget

There is no budget for this research project. Participants will have to voluntarily participate without expecting compensation.

Target User Group

The following outlines the user profiles for software developers who showcase and prepare programming projects with the purpose of:

Creating educational and informative programming tutorials

• 7 out of 8 total participants recruited

Showcasing informational slide show presentation

• 0 out of 8 total participants recruited

Conducting a live programming demo

• 1 out of 8 total participants recruited

The ideal research study would total 24 participants per target user group.

Recruitment

Participants will be sourced through various channels, including Reddit, Meetups, social media, programming forums, and Discord. Prospective participants will be required to complete a screening survey. The most suitable candidates aligning with the user profiles will then be selected for interviews. Ideally, I aim for 8-12 participants per target user group to properly assess their tasks, behaviors, pain points, and unmet needs. The total of participants will be greater than or equal to 24.

User Interview

• Conduct interviews with a minimum of 8 participants to gain qualitative insights about the tasks, habits, behaviors, pain points, and overall process of presenting and preparing code.
• Explore scenarios where challenges are most pronounced and understand the impact on developers' workflow.

Competitive Analysis

• Analyze competitors in the code presentation tools market to understand the landscape and identify potential gaps or areas for improvement.
• Evaluate the strengths and weaknesses of competitor products through hands-on testing and feature comparison.
• Consider user feedback on competitor products to extract valuable insights into user expectations and areas of discontent.

Timeline

The following are based on estimates

Milestone Estimated & Timeframe Completion

• Competitive analysis: 1-3 days
• Screener survey: 1 day
• Recruiting participants: 1 month
• Interview: 1-2 weeks
• Affinity diagram: 2-3 weeks
• Task analysis & Optimization: 2-3 weeks
• Research report: 1 week

Deliverables

• Task analysis & Task analysis Optimization
• Affinity diagram
• Research report
• User Insights
• Competitive Analysis
• Knowledge Quadrant
• Problem Statement

Risk And Challenges

• Lack of budget might impact participant recruiting
• Not meeting the minimum amount of participants due to a lack of participation
• Lack of oversight and feedback from the research team

Tools

• Notion

Research Plan

Defined the interview plan outlining objectives, target user groups, recruitment process, interview script, questions guide, and more in preparation for the user interview.

Before conducting the interview, I first needed to understand the key components and objectives of a well-structured user interview, for this reason, I created a user interview plan. The user interview plan helps me outline the methodology for conducting user interviews. Key components include defining objectives, target user groups, recruitment process, interview script, questions guide, roles, tools, project timeline, findings, and analysis. The interview plan is structured to answer the questions and objectives from the knowledge quadrant and research plan. The result of a well-executed user interview plan is a rich source of qualitative data that clarifies questions and assumptions from the research plan. In the interview plan, I defined 24 questions for the user interview. Each question was organized based on themes derived from the research plan I wanted to explore.

I used the knowledge quadrant exercise and other secondary research information to come up with 9 themes for the interview questions guide.

User interview question themes

• Warm-up: Simple on-topic questions related to their motivations for making programming presentations.
• Project planning: Understand if developers write code before planning, analyze factors influencing project selection, and investigate the impact of source code size on decision-making during project preparation.
• Code setup: Examine developers' process in configuring projects for presentation, assessing whether they organize code content with defined key sections, and the overall flow of their code preparation.
• Notes: Evaluate developers' note-taking practices for projects, explore how and where they document notes, understand the note-taking process, and identify the tools commonly used by developers for this purpose.
• Code presentation: Delve into the dynamics of developers presenting their code, identify common challenges faced during coding demonstrations, and understand developers' specific needs and expectations concerning coding presentations and error handling.
• Tooling: Identify user preferences for code presentation tools, including conventional ones like Keynote or PowerPoint and code-oriented tools like Animotion or Motion Canvas. Evaluate the frustrations and strengths associated with their tools in facilitating code presentations.
• Efficiency metrics: Assess developers' time spent on setting up and organizing code, quantify the investment of time in code documentation and presentations, and evaluate tasks based on manual intensity, cognitive demand, error-proneness, and knowledge dependence.
• Ideations: Analyze the ideal solutions a participant suggests for solving their code presentation hurdles.
• Wrap-up: Address the participant's feedback and questions.

Created a screener survey to identify and select individuals who meet specific criteria for participation in the user interview. Due to recruiting difficulties, I settled for recruiting 8 participants instead of the targeted 24 candidates.

Recruiting the right participants for the research study is essential for generating quality data. For this reason, I used a research screener survey as a tool for recruiting the targeted participants for the user interview. Its primary purpose is to help me identify and select individuals who meet specific criteria for participation in the user interview. Based on the target demographic, I created a survey of 10 questions that would help me filter out the best candidates for the study. As a result, I managed to successfully recruit at least 8 participants for the user interview study. One big issue I faced with recruiting was finding people for the study. I spent a long time trying to get the right participants. Even though I reached out to potential candidates directly, I got a lot of no responses and cancellations. That's why I ended up recruiting only 8 participants instead of the planned 24. If I had a budget, ideally I would have liked to recruit 8-12 participants for each of the 3 targeted user groups.

Lack of Participants and Diversity Challenges

Recruitment challenges prevented me from securing the desired 24 candidates, including those with accessibility needs. This limitation affected the data aggregation process for user interviews, as well as the analysis and synthesis required for affinity mapping and task analysis. Among the three target user groups, most of the participants came from group one shown below.

Target User Group

The following outlines the user profiles for software developers who showcase and prepare programming projects with the purpose of:

1. Creating educational and informative programming tutorials

• 7 out of 8 total participants recruited

2. Showcasing informational slide show presentation

• 0 out of 8 total participants recruited

3. Conducting a live programming demo

• 1 out of 8 total participants recruited

Solution & Considerations

Ideally for recruiting, having a budget, an adequate amount of time, and a team of experienced researchers would have allowed me to screen and recruit the ideal 24 candidates and people with accessibility needs.

Overview

The goal is to gain a deep understanding of the code presentation market landscape and identify potential gaps or areas for improvement. This involves hands-on testing and feature comparison to evaluate the strengths and weaknesses of competitor products. I will also delve into user feedback on competitor products to extract valuable insights into user expectations and areas of discontent. The main objective is to inform strategic decision-making by identifying opportunities for improvements within the code presentation tools market.

Strengths & Weaknesses

Keynote

Strengths

• Pre-installed on Mac computers, making it readily available
• Industry-standard general-purpose presentation tool
• Intuitive and user-friendly interface with a low learning curve
• Abundance of online resources for learning how to use the tool

Weaknesses

• Exclusive to Mac OS
• Not designed for displaying code, lacking syntax highlighting, formatting, and code integration
• Limited utility for showcasing code effectively

Animotion

Strengths

• Free and open-source
• Platform agnostic, catering to various operating systems
• Robust code support and multimedia capabilities
• Versatile, allowing the addition of JavaScript libraries
• Functions as a playground for testing products
• Well-documented for ease of use

Weaknesses

• Geared towards web developers, requiring proficiency in JavaScript, HTML, CSS, and Svelte
• Dependencies are necessary, adding complexity
• The steep learning curve for beginners
• Lacks a graphical user interface (GUI), relying entirely on code

HackerTyper

Strengths

• Free and compatible with Visual Studio Code, a widely used code editor
• Utilizes Visual Studio Code's features for enhanced functionality
• Enables building and running projects, reflecting an authentic programming environment

Weaknesses

• Exclusively tied to Visual Studio Code
• Missing crucial code presentation features such as adding presenter notes, presenter screen, and code prepping
• No GUI; operates as a plugin, requiring familiarity with Visual Studio Code
• Subpar user experience, providing little context or direction on code organization

Potential Study Flaws

Limited Pool of Participants

Ideally 8 to 12 participants per target group needed to be recruited for a diverse set of data aggregation. In total, I needed to conduct about 24 interviews to get a better assessment of the problems, tasks, and behaviors of each target user group to gather diverse research data. Due to the lack of budget, time constraints, and general complexity of finding and recruiting participants, appointment cancelations, or no-shows, I had to compromise the research study and use 8 participants.

Lack of Participants With Accessibility Needs

0 participants with disabilities or accessibility needs were recruited or interviewed to analyze potential UX concerns and problems, therefore biasing research for able-bodied individuals.

Improving Research Insights Using Contextual Inquiry

Considering the main purpose of this study was to understand the idiosyncrasies of the participant's tasks regarding presenting programming projects, I should have considered ethnographic research instead of user interviews to better asses their actions, interactions and observed behavior, and any missed opportunities that were not accounted for in the interview.

Participants

8 out of 8 of the participants are male. Most work in the tech industry as software engineers. Their experience ranges from front and back-end web development to video game and mobile app development. The majority of the participants create content for teaching and sharing programming knowledge. All participants are considered power users considering they are software engineers possessing knowledge-dependent whereabouts using an array of complex and industry-standard tools to develop and troubleshoot their projects.

Findings and Insights

Code Build Order & Setup

Code Organization and Build Order

• P1: Writes comments on their code sequentially numbering the build order. They like to show how they create every single line of code believing it's more natural and appreciated by the audience.
• P2: Likes guiding viewers through each step, and organizes code sequentially to use the code as a reference. They like to go through the entire code repeatedly until they feel comfortable explaining all the project details. They also make sure to cover things in the right order, following a logical sequence for coding.
• P3: Organizes code based on build order writing notes that serve as a reminder to cover/explain code. Groups code into smaller projects that will eventually be turned into tutorials. They do this so they don’t get overwhelmed with making one long video and it's easier to track code because the projects are a lot smaller.
• P4: Normally writes scripts for complex projects covering important aspects of the code. The script helps structure the tutorials in a manner that is clear and orderly and helps them explain programming concepts or code in great detail. The script is responsible for organizing the code, which helps them know what code goes next.
• P6: Reviews the project source code, comments out sections that will be uncommented and explained later in the tutorial, and uses a script as a guide for indicating the code build order and for indicating pointers for telling them when they need to copy/paste code and when they need to transition to the next piece of code. This step is crucial because sometimes they forget what code came first.
• P7: They Write comments next to the code to show good and bad examples when explaining the code. When presenting, the code examples are commented/uncommented where appropriate.

Time Investment and Complexity Considerations

• P1: Writing notes to set the code build order can take a while to document because they have to think and plan on what code comes next.
• P2: Code setup takes about an hour; Recognizing that programming isn't always written from top to bottom, they acknowledge the need to review the code back and forth. As a result, arranging and pasting code in the correct order is a time-consuming process, and this duration varies depending on the size of the project being worked on.
• P3: Code organization is a time-intensive process; 2-4 hours is dedicated to preparing the code and any material. ”My process is very time intensive which is why I don’t post as often”. Time-consuming processes include editing tutorials and preparing presentation material.
• P4: Writing scripts and organizing code can take time, especially for complex projects.
• P5: Time spent making a video from scratch ranges from 1-3 hours on average.
• P6: Most if not all of their code is copied and pasted to save time. Editing and setting up projects' code are the most time-consuming tasks.
• P7: Setting up code takes 30 mins to 1 hour; Recently they’ve been making shorter videos because it takes less time. Setting up projects' code and editing are the tasks that take the most work; creating slides and animations can also be time-consuming.

Tools/Features For Setting the Code Build Order

• P1: Used Keynote for organizing code but gave up on the app when trying to set the animations build order of their code making the process frustrating. Keynote lacks important features for presenting code, like adding syntax highlighting or formatting.
• P2: Used a slide show presentation software for trying to organize the project's build order however they found that the features aren’t suited for setting up code. Syntax highlighting and formatting challenges and setting animation order.
• P6: Tried using Keynote once but after tinkering with it for a while they decided it wasn’t the right tool for what they were looking for. They were too frustrated trying to copy and paste code and a lot of the source code editor features were missing.
• P7: Utilizes Keynote for technical screencasts with animations; sets the order using build order functionality.

Suggestions and Opportunities

Code Organization and Build Order

Build a system that allows developers to sequentially group code in whatever order they prefer. The system would allow developers to dynamically group code by character, line, or blocks thus addressing their issues of tediously manually ordering code. The system would allow the developer to dynamically set the build order of every piece of code giving the developer the freedom to write as much code without having to worry about the complexity of the project's source code when preparing the code for presentation. The Build system would allow developers to group the code they want to emphasize when discussing a concept related to the highlights code. The system can also meet other developer code presentation needs such as replacing, deleting, and highlighting code.

Time Investment and Complexity Considerations

Building a system that streamlines a developer's build order code preparation process would significantly reduce the effort and error-prone nature of manually grouping code thus enhancing the developer's productivity. To further improve the system, AI can be used to predict common code grouping patterns based on common syntax formatting structures, and build patterns. Developers can upload their source code files directly to the system allowing for easy modifications to source code files.

Tools/Features For Setting the Code Build Order

The main feature of grouping code will be prominent on the UI allowing users to quickly access the tool or use key commands as shortcuts for grouping code. The system will support the majority of programming languages allowing developers to modify system settings like code theming, formatting, syntax highlighting, and text accessibility settings. Similar to the Keynotes presenter screen feature, the system can demonstrate the code build order to inform the developer of the code that is going to be shown next and an overview of the presentation's source code.

Typing Code

Challenges and Frustrations, Error Prone

• P1: When presenting, they’ve expressed being frustrated with retyping source material, leading to typos and errors, taking away focus from the content. “The biggest frustration I have with presenting code is the fact that I have to retype the source material that I prepared leading to typos errors and occasional bugs which take time to find and fix”
• P2: Dislikes typing code from scratch, and finds it error-prone and time-consuming.
• P3: For complex projects, they spend more time in general writing code, however, they try to avoid written code as much as they can because it’s very error-prone, and don’t want to introduce bugs. Writing code can be difficult because they have to constantly check their notes and reference code all the time which can get confusing.
• P4: Retypes code step by step from a sample repository. Multitasking with reading notes, code, and typing code can be overwhelming making avoiding errors a challenge. When typing code, they try to do their best to not make any errors or mistakes so they don’t spend too much time editing. They make mistakes while typing code, such as typos, miss-placing code, and forgetting to write code which disrupts their flow.
• P5: Believes that real-time coding tutorials, where the programmer types each line, are slow and prone to mistakes, they like taking a different approach to content creation. They stress how important it is to write the code themselves to understand how it works and to work out any kinks.
• P6: Doesn’t like typing code because they make a lot of mistakes. They decide not to re-type code because it is error-prone and it saves them a lot of time.
• P7: Believes it's important to write the code line by line. They find people who copy and paste code frustrating because too much information is shown which makes it hard to follow along.
• P8: “Sometimes when recording the video and I am typing the code, I make mistakes, a lot of mistakes because you know I have to type everything” They make a lot of mistakes when live coding, sometimes these mistakes are typos, misspellings, missing code, or errors that prevent them from building and running the code. When live coding, they take audience questions, occasionally going "off script" to explain concepts through additional code writing.

Time Investment in Typing Code

• P1: Takes 30 min - 1 hour for long programming projects, involving typing, explaining, and fixing mistakes. “It also does not help that I have to spend quite a bit of time just typing the code instead of focusing on the material I plan on covering”
• P2: When live coding, they figure things out in the moment without much planning which takes longer because they are solving problems as they arise, often making mistakes that lead to errors and bugs, and fixing things can be time-consuming.
• P3: Half of the time for larger projects is dedicated to explaining and typing code. Some projects are over 11 hours worth of content so for those projects they spend more time in general writing code.
• P4: Time spent typing code varies based on familiarity and research, ranging from 10-15 minutes to a couple of hours. Having to record themselves and retype the sample repository code again on Visual Studio Code can be frustrating at times because typing takes a long time and you are always bound to make a mistake. They believe that recording themselves re-typing the sample repository and postproduction work like editing the video is what's most time-consuming for them.
• P6: Writing the code for the project can take a long time depending on the amount of code they have to write and the research they have to do. Prefers avoiding typing code due to frequent mistakes, believing it saves time.
• P7: The time spent on making tutorials depends on the size of the source code. Some projects are short others are long. They take longer to show code because they have to type the code line by line sometimes.

Efficiency and Automation

• Many Participants expressed their desire for automation tools to help them automate typing code among other functions to enhance their productivity.

Suggestions and Opportunities

Challenges and Frustrations, Error Prone

To circumvent errors, warnings, typos, and other human errors, the system needs to take care of automating the process of typing code. The system can simulate the typing of code leaving the developers to focus on presenting their projects. This system will allow the developer to transition their code similarly to how someone would transition through a presentation slide. Using a custom keystroke a developer can transition through their whole code with the touch of a single button. A developer can transition back and forth through their code without having to worry about typos or compiler errors.

Time Investment in Typing Code

The developer can run their presentation, theoretically as many times as possible without making a single mistake because the system will take care of writing the code for them. No more would the developer spend hours or minutes typing, copying/pasting their code when presenting; when stressed for time, the developer can set the speed of the typing of code, making it faster or slower as they see fit.

Notes and Documentation

Annotating Code for Build Order and Documentation:

• P1: “Annotating the build order of the code is the most important process because it tells me what code I need to write next, It is also the most annoying part because it just takes too much of my time” Documenting code also consists of adding notes next to code that they feel like needs to covered in depth.
• P2: Writes notes whenever possible to document code, it serves as a reminder for them to cover specific topics or explain certain sections of code. Notes are organized into themes corresponding to the project's code.
• P3: Takes notes to indicate the order of typing code. Writes Notes mostly for adding commentary and documenting pieces of code. When setting up their project, they review their code and write notes that serve as a reminder to cover/explain code.
• P4: In some videos, they write full scripts, and in other videos, they write bullet-point notes. For more complex projects, they create a script that covers crucial aspects of the code. The script structures tutorials in a clear and orderly manner, facilitating detailed explanations of programming concepts or code. It plays a key role in organizing the code, guiding the presenter on the sequence of code segments, and ensuring a cohesive and comprehensible presentation.
• P5: Chooses not to write a script for videos to avoid sounding scripted, occasionally leaves code comments. Instead, they opt for doing voiceovers recording audio in small parts almost sentence by sentence.
• P6: Writing a script is something they often do, especially for coding tutorials, sometimes they go off the cuff. Uses the finished project as a reference when writing the script to see what programming concepts they need to cover and code they need to explain. The script serves as a guide, indicating when to copy/paste code and facilitating smooth transitions between code segments. Constantly references the script during video creation. To save time, they prefer using copy-and-paste methods for presenting most, if not all, of the code. When recording tutorials, their process involves them reading the script and uncommenting pre-written code when they cover that part of the project in whatever order they plan on showing the code.
• P7: Utilizes good and bad code examples on the project and comments/uncomments the code when appropriate. Writes notes/comments usually on the sample project source code. The Sample code is commented out to avoid interfering with the final source code.
• P8: They add comments next to the code to document the code and remind them of what should be written first. They also write comments directly to their reference code for presentation purposes. They review their whole reference code and write comments on the code to guide them in presenting code and doing commentary. The side notes help them navigate through the project to make presenting code in an orderly manner easier.

Tools Used for Note-Taking and Documentation

• P1: Writes their notes on Visual Studio Code after the code has been written.
• P2: Writes notes in OneNote to document code, organizes code into themes, and avoids excessive notes for better source code readability.
• P4: Manages video ideas in Notion, using bullet points or scripts depending on project complexity; script-writing time varies.
• P6: Uses Google Docs for notes and annotations and highlighting their notes.
• P7: Adds comments next to code for good and bad examples, avoids scripted content, and writes notes in Keynote for explanations.
• P8: Prefers Google Docs for documentation and Google Slides for theory-based presentations. Uses Google Docs for writing documentation and comments directly in the reference code; spends around an hour writing notes for a presentation.

Challenges and Frustrations

• P1: Annotating is time-consuming, especially when reviewing the whole code; wishes for a better option for adding notes. “It would be nice if there was a better option for adding notes to my code as adding too many notes makes it hard for me to read the reference material when I present code”
• P2: They are cautious not to write excessive notes, as it can make them difficult to read on their second monitor. The second monitor is divided between the notes and the code, serving as a reference for them.
• P7: The Sample code is commented out to avoid interfering with the final source code.
• P6: Frustrated with pre-production and post-production tasks, including researching topics and editing footage, audio, and visual effects.

Time Spent on Note-Taking

• P1: “Too much time if you ask me” The time varies from project to project but it can take anywhere from 30 min to 1 hour”
• P2: Estimates spending around 10-30 minutes writing notes but mentions that it depends on the project size and depth of the project. For bigger projects with more complex code, it could take more time.
• P3: Dedicates 10-30 minutes for note-taking, longer for larger projects; emphasizes the importance of well-annotated code because it makes recording videos easier.
• P4: The time spent writing scripts for tutorials varies based on project size and the depth of coverage desired. Scripting can take 30 minutes to an hour, depending on the extent of detail the participant aims to cover in the tutorial. The size of the scripts is influenced by project complexity and the level of explanation required.
• P6: Spends 20-30 minutes writing notes, and uses Google Docs for annotation and highlighting.
• P7: Spends maybe 10-25 minutes writing notes, It depends on the project and the amount of research that is needed.
• P8: Depending on the size and complexity of the topic, it usually takes them an hour to write notes for a presentation, especially if they need to conduct research.

Authenticity vs. Scripted Content

• P7: Prefers authentic content, avoids scripted videos; and writes comments next to code for authenticity.
• P5: Chooses not to write a script to maintain a natural, unscripted feel in videos.
• P6: Often writes scripts for coding tutorials, uses the finished project as a reference, and includes pointers for copying/pasting code.

Referencing Code and Navigation

• P1: Keeps their reference material on a secondary monitor for referencing when making tutorials.
• P2: They are cautious not to write excessive notes, as it can make them difficult to read on their second monitor. The second monitor is divided between the notes and the code, serving as a reference for them.
• P3: Keeps notes on a second monitor for reference during video recording.
• P4: Has multiple monitors for placing their notes and code.
• P6: Uses the finished project as a reference when writing scripts, ensuring coverage of programming concepts.
• P8: Reviews the whole reference code and writes comments to guide code presentation and commentary.

Suggestions and Opportunities

Annotating Code

A system can be built specifically for adding notes to code. Similar to Keynote's ability to add presenter notes on slides, the system would allow the participant to add notes to any character, word, or block of code to their project. Notes can be modified to their liking and will co-exist with their code only being shown when necessary to avoid distracting the developer.

Tools Used for Note-Taking and Documentation

The system would handle documenting every note of the participant. Participants would no longer have to worry about writing their notes on a separate notes application or on their source code which can make code harder to read impacting their cognitive thinking. An AI system can be used to write explanations of selected code making it easier for the developer to research and explain topics.

Time Spent on Note-Taking

Due to the system's simplistic nature of annotating code, developers no longer have to spend countless minutes or hours finding and documenting their code which can be a manually intensive task. No matter the project's complexity or size, the system's rudimentary nature will allow the developer to easily add notes on a whim.

Referencing Code and Navigation

Similar to Keynotes presenter notes features when presenting a project, the system would handle showing their notes on the presenter screen when they transition to the code that has been annotated. The presenter screen will show them the relevant notes in context to the code that has been annotated. The participant can use the presenter screen as a guide to see what annotated code comes next. Because the system will handle showing their notes and code in an orderly manner, they no longer have to multitask reducing cognitive load and facilitating presenting code in general.

Source Code Size & Complexity

Project Creation Frequency

• P1: Work frequency depends on project complexity; long projects take a month, and simple ones take 2-3 weeks. Currently, they don’t make projects as often as desired due to the substantial amount of work it takes to make presentations.
• P2: Project creation frequency varies based on project size; big projects take a month to create while smaller ones are created every two weeks.
• P4: Project creation varies, sometimes they make 2 tutorials a month and sometimes 1 every two months. They work full-time as a full-stack developer and making tutorials takes a lot of time and energy, for this reason, they don’t upload as frequently as they would like to.
• P6: 2-3 presentation projects are created a month but the development of projects depends on the type of content they are making, longer form videos courses require more work taking hours to make therefore they are made less frequent.

Presentation Project Size, Lines of Code (LOC) per Project

• P1: Typically generates around 1,000 LOC per project, including boilerplate code.
• P2: Depending on the project, the source code can range from a couple thousand LOC for big projects.
• P3: Source code size varies, for small projects, the amount of source code can range from 40 lines of code to a couple thousand LOC for larger projects not including framework-related boilerplate code.
• P4: Tutorials over 2 hours usually have a couple hundred to a thousand LOC, depending on project size and complexity. The size and complexity of the project usually determine the length of the video, therefore, longer videos mean more code they have to write and cover and shorter videos imply writing less code for small projects.
• P5: Focuses on simplicity; source code size ranges from a couple of lines to a few hundred.
• P6: Projects range from a couple hundred to thousands of LOC; long-form content takes hours to make.
• P7: Source code size depends on the complexity of the project. Usually, their projects contain a couple of hundred LOCs, and even fewer LOCs for smaller projects.
• P8: Projects vary in complexity, with some OpenGL projects having a lot of rendering code. Most projects are a couple hundred to a couple thousand lines of code.

Video Length and Content Strategy, Time Investment

• P2: Presentation lengths vary and depend on the size of the project. Typical video lengths are 15-30 mins for tutorials, and 1-2 hours for live coding sessions, lasting longer due to their impromptu nature and real-time problem-solving.
• P3: Time spent on projects varies from 30 minutes to over 11 hours for large tutorials.
• P4: Making tutorials takes a lot of time and energy; time spent depends on project size. Longer videos imply more code to write and cover, and shorter ones for simple projects.
• P5: The majority of videos are short, ranging from 3-8 minutes.
• P6: Tutorial duration varies based on source code length. The average video length is about 1 hour and 30 minutes, focusing on long-form content.
• P7: Spends about 30 mins to 1 hour setting up code; time spent on tutorials depends on source code size.

Content Complexity and Preparation

• P1: Tries to avoid complexity to make programming tutorials easy. “Usually I end up making tutorials on showing people how to make simple fully functional apps and try to avoid complexity as much as possible to make programming tutorials easy”
• P2: Ensures topics aren't too complex to minimize preparation time.
• P5: Prioritizes simplicity therefore creating smaller less complex programming projects with small to medium-sized code.
• P7: Frequently focuses on topics that require little research for short-form videos requiring minimum effort.

Suggestions and Opportunities

Automation Increases Project Creation Frequency

With the aid of the systems automating the majority of the presenter's tasks, developers won't have to worry about the complexity and source code size of their projects because they won't have to organize code and document code leading to developers being more productive and creating more tutorials.

Error Prone Task & Bugs/Errors

Code Review and Bug Checking

• P1: Reviews source code to ensure it builds and runs error-free, addressing bugs, updates, or improvements.
• P2: For complex programming projects, they stream themselves live coding without much prior planning, addressing coding issues as they arise. This approach leads to mistakes, errors, and bugs, making the debugging process time-consuming. “it's good for me when I copy and paste in the code because it's less error-prone if you go running your code you're rarely going to have a syntax error which makes it easier for me to record tutorials”
• P3: Checks projects for bugs, and errors, and ensures functionality; They want to make sure the project is functional and any framework they use is updated to reflect the latest version. Editing and deleting source code files can be challenging as it disrupts the workflow. However, regularly building and testing the code is beneficial for identifying errors and bugs and showcasing progress to the audience.
• P4: They write the code initially for the project and check for warnings and bugs introduced during the coding process.
• P6: Checks the project for bugs, typos, or warnings to make sure the code is functional; This step is important because they don’t want to be sharing code that is buggy and nonfunctional.
• P7: Ensures code quality by checking for bugs or performance improvements when writing code.
• P8: They make a lot of mistakes when live coding that prevent them from building and running the code. Upon encountering an error, they review the code for simple mistakes like typos, misplaced code, or fixable compiler errors. For more complex issues, they refer to their reference code to ensure consistency between projects. Their troubleshooting approach prioritizes resolving the problem quickly, reflecting a preference for efficient error resolution without extended time investment.

Handling Errors

• P1: Edits out parts involving fixing mistakes or bugs during video editing; re-records parts with errors in the script.
• P2: If errors occur, they either redo the task or edit out the mistake during the video editing process. Errors are annoying because they disrupt the flow of their presentation and cause them to spend more time on the presentation than needed.
• P3: Accounts for errors in post-production, cutting out mistakes, or re-explaining parts; bad sections are edited out from the final video.
• P5: Errors consist of misspeaking or misreading the script; mistakes, pauses, and unwanted material are edited out in post-production.
• P6: All mistakes, long pauses, loud noises, and unwanted material are edited out and corrected in post-production.
• P8: Makes mistakes when live coding, especially typos, and errors; reviews code for simple mistakes and troubleshoots more complex errors.

Use of External Tools

• Participants who need to check their code for bugs, warnings, and errors need to build and run their code using a source code editor that allows them to compile their code. Most participants use VSC for debugging building and running code.

Suggestions and Opportunities

Code Review and Bug Checking

Some participants expressed their desire to build and run their projects on their preferred development environment to test the code for bugs, errors, and performance improvements. The system should allow the developers to present their code on their source code editor of choice allowing them to use their ideal tools and systems to troubleshoot code. Because the system is going to automate typing code, developers won't have to worry about mistakes, therefore, streamlining their presentation process and making their workflow more efficient.

Handling Errors

Participants will no longer have to spend minutes or hours editing their mistakes or prolong their tutorials trying to fix errors because the system will automate most manually intensive error-prone tasks.

Cognitively Demanding, Multitasking

Challenges in Referencing Material and Multitasking

• P1: Uses their laptop as a secondary screen for referencing material while presenting or live coding on their main desktop. The back-and-forth between referencing their sample project and the code being written can be overwhelming, leading to a potential loss of focus.
• P2: Acknowledges the non-linear nature of programming and the need to go back and forth between code sections can be cognitively demanding. Using a second monitor, they divide the screen between notes and code for effective reference but notes that jumping between monitors can be confusing.
• P3: The participant divides code into smaller projects to avoid feeling overwhelmed during tutorial creation. They use a second monitor to jump back and forth between reference code and notes but note that multitasking in this manner can be challenging.
• P4: Multitasks when recording tutorials by having two screens, one for the sample repository and the other for the new coding repository. They multitask by reading notes, coding, and typing simultaneously, acknowledging the potentially overwhelming nature of this process.
• P6: Multitasks by reading scripts, uncommenting pre-written code, and copying/pasting code as needed during recording, aiming to avoid distracting viewers with excessive content.
• P7: Emphasizes the importance of showing only relevant code during video recording to avoid distracting viewers. They prefer presenting code line by line rather than copying and pasting large sections to enhance clarity for the audience.
• P8: Utilizes a second monitor for reference code to check when making errors during coding.

Suggestions and Opportunities

Challenges in Referencing Material and Multitasking

Participants expressed their concern with multitasking and cognitively demanding tasks leading to confusion and making mistakes. Multiple systems can be put in place to handle the majority of manually intensive error-prone tasks. These systems include the ability to sequentially group code in an orderly manner, the ability to annotate/document any piece of code, automate rudimentary common developer tasks like creating, and deleting files/code custom mouse and keyboard action, and the ability to have a dedicated presenter screen showing the developer relevant information that will help them present their projects.

Testing, Building, And Running Code

Writing and Testing Code

• P1: Reviews the project's source code because they write a lot of code, they make sure that it builds and runs without any errors, they also check for any bugs and updates and improve the code if needed.
• P2: Builds and runs their code in the terminal to check for errors, warnings, and bugs.
• P3: Test their code and check for improvements, updates, or errors.
• P4: Prioritizes writing and completing the tutorial code first to circumvent mistakes during recording. They regularly run their projects to identify warnings, and bugs, and ensure smooth functionality.
• P6: Runs the project to observe code results and utilizes the terminal in Visual Studio Code (VSC) for debugging and executing commands.
• P7: Emphasizes checking for bugs and performance improvements while writing code to ensure everything functions correctly.
• P8: When writing the code they constantly test the project to see if everything works accordingly. Their process includes actively typing and explaining code or concepts to the audience while consistently building and running the project to test the code. This dynamic approach allows them to showcase real-time results to their audience throughout the tutorial or presentation.

Suggestions and Opportunities

Writing and Testing Code

The system will be a separate entity that will enable the developers to sequentially order code, annotate, and add automative actions to facilitate the preparation and presentation of programming projects. If developers want to build and run their code for testing purposes or to show results, they can accomplish those tasks because the system would not interfere with the developer's tools and would mainly serve as a complementary autonomous system.

Tools, Features, and Software Layout

Source Code Editors

• P1: Uses Visual Studio Code (VSC) and Xcode for source code editing. Visual Studio Code is not meant for presenting code therefore they have to do the bulk of the code presentation prep work. Prefers using Visual Studio Code as it allows them to write, modify, debug, and build code in real-time, reflecting their actual work process, and appreciates its flexibility, extensive functionality, and popularity among source code editors.
• P2: Prefers Visual Studio Code for coding and OneNote for note-taking, expressing the need for automation features within VSC to improve productivity. When they need to run code they switch to the terminal window to check for bugs or errors. They find features such as syntax highlighting and the wide range of plugins to be valuable. The ability to type code directly in the editor, along with the capability to debug and run applications in real-time, adds to the overall positive experience with Visual Studio Code.
• P3: For most projects, they use Sublime Text as their preferred source code editor primary for the styling. They like Sublime Text because adding clear and easy-to-read syntax highlighting and formatting is important for them because it makes the code easier to scan. When making tutorials they need to have a clean work environment that is free from distractions and anything that is not relevant to the presentation.
• P4: Utilizes Visual Studio Code for source code editing. For Visual Studio Code, they like the fact that they can set up their development environment, and it's their tool of choice when doing web development, having different themes, and syntax highlighting options is always nice to have.
• P5: Enjoys Visual Studio Code for source code editing, favoring it for its massive functionality, customization options, and a large supportive community. They appreciate the ability to change syntax highlighting themes and adjusting text size, ensuring code readability, especially on smaller devices.
• P6: When using Visual Studio Code, they prioritize displaying as much code as possible, removing distracting UI windows for the viewer's clarity. They keep their script and reference project on a secondary screen. To cater to mobile users, they ensure text size is maximized in VSC. Additionally, they use their cursor to highlight and provide context for the code they are explaining. They like how they can use the terminal in VSC to debug code or run commands.
• P7: Uses VSC for their preferred source code editor. In VSC they like choosing a font and syntax highlighting that is readable and has good contrast.
• P8: Uses VCS as their preferred source code editor and a large array of plugins. Github for submitting and sharing their source code.

Presentation Software Features and Tools

• P1: Used Keynote for trying to present code but expressed dissatisfaction due to its limitations in effectively displaying code. Attempting to organize code was frustrating as Keynote lacks essential features such as syntax highlighting and formatting, which are crucial for presenting code effectively.
• P2: Used Keynote for animations and visuals but faced challenges with code presentation features such as syntax formatting and highlighting. Their process includes copying and pasting code from Visual Studio Code (VSC) into Keynote. In Keynote, they enhance the presentation by adding animations and visuals. Due to issues with code pasting in VSC, they make modifications, such as adjusting the background color in Keynote to match the code's background color, ensuring a seamless visual presentation.
• P3: Their presentations are split between showing visuals in post-production, showing chunks of code, and using After Effects to automate the typing of code. When covering the code sometimes they use Epicpen to write on the screen to explain concepts.
• P4: Uses Notion for managing video ideas. They have used PowerPoint before but not for programming. However, they appreciated its structured format for presenting content and found its animations and transitions to be appealing.
• P5: Uses Adobe Premiere for voiceover recording. They have never considered using presentation software to help them make tutorials. The process of adding animations for code and visuals in After Effects, along with video editing, is time-consuming. They often experienced frustration during the recording and editing stages, especially when they needed to do multiple retakes making the process tedious. Occasionally, they find it necessary to take breaks due to the repetitive nature of the recording process.
• P6: Uses Google Docs for writing notes and annotating/highlighting. They tried using Keynote once but after tinkering with it for a while they decided it wasn’t the right tool for what they were looking for. They were too frustrated trying to copy and paste code and a lot of the source code editor features were missing.
• P7: Combines Visual Studio Code with Keynote for technical presentations and animations. When creating technical screencast they use a lot of slides and they make sure to use as many animations as possible to allow them to teach one thing at a time to keep things engaging. They also like to use sophisticated animation on Keynote to teach advanced topics. They like using Keynote's build order functionality to arrange the sequence of animations in their presentation. Once the slides are complete, they export the animations to a video format and leave the editing process to the video editor. The creation of slides and animations is a time-consuming task for them. Faces challenges in Keynote when trying to copy and paste code with syntax highlighting. To overcome this, they resort to a workaround by copying the code into TextEdit to remove the background, then paste it back into Keynote. They’re frustrated with needing to use a source code editor to add syntax highlighting to Keynote.
• P8: They use Google Slides when they need to explain more theory-based topics. Google Slides helps them add visuals and animations to make the concepts easier to explain. They like animating through code when they don’t feel like typing or when they are working on smaller projects.

Desired Features and Automation

• P1: In VSC, there is no way to automate typing pre-written code. And there is no way of setting the build order of your code. VSC lacks a lot of automation tools that can help them automate a lot of their error-prone and mundane tasks. They want a way to simplify organizing code, add presenter notes, and improve workflow productivity by automating mundane tasks like typing code.
• P2: Expressed interest in Visual Studio Code to incorporate plugins that could automate certain code-related preparatory work, like auto-typing code to save manual effort similar to some of the animation functions of Keynote. They believe adding Keynote features that can automate manual tasks such as typing code and navigating the project would make them more efficient.
• P3: To streamline their process, they write extensive code in After Effects to automate tasks. Most of the code displayed to the viewer is animated using visual effects, simulating the process of typing code. This automation approach saves approximately 20% of their time, despite the initial investment of time required for setting up the automation.
• P4: They are not aware of any plugins or tools within VSC for automating their task but they would love to download any plugins that may help them improve their productivity so they can make more tutorials.
• P6: Desires a feature in Visual Studio Code that enables them to quickly clear the editor of distractions and unproductive UI elements with a single click. This feature would allow them to change the layout and settings for presenting code, including making text bigger, enhancing contrast, incorporating a typing plugin, and adding custom keyboard shortcuts for macros and other functionalities.
• P8: For presentations in which they don’t want to write code, they use Google Slides to automate writing the code. For these projects, they mostly focus on showing and explaining code which makes it easier and less error prone. Because they spend most of their time on VSC they would like to use more plugins for helping out with live coding presentations. Things like adding custom macros for automating code chunks, and keyboard and mouse actions.

Multiple Screens, Layouts and Settings

• P1: Uses a laptop as a secondary screen for reference material, using the main desktop for live coding. Switching between screens can be overwhelming at times.
• P2: Uses a second monitor, dividing it between notes and code for easy reference during presentations.
• P3: Splits their secondary monitor between notes and a reference project, keeping their source code editor open on the main screen. Ensures that Sublime Text is set up with proper settings and UI presentation layout before recording, focusing on code readability and minimizing distractions for viewers.
• P6: Emphasizes setting up recording software on the primary screen, optimizing text size for mobile users in Visual Studio Code (VSC), and expressing a desire for a feature in VSC to clear distractions and adjust code presentation settings.
• P8: Commonly uses a second monitor for their reference code, especially when encountering issues and needing to check their code.

Suggestions and Opportunities

Source Code Editors

The system is not a source code editor but it will incorporate features like support for syntax highlighting and formatting for the majority of programming languages, accessibility features that will allow the developers to change the text size of code among other settings, and a minimal non-intrusive UI layout to avoid distracting viewers making the code and concepts being discussed the main attraction. Developers will still be able to use their desired tools without having to compromise their workflow.

Presentation Software Features and Tools

A great amount of inspiration will be taken from presentation software like Keynote and PowerPoint for developing creative systems that will help address the common pain points of the participants. Some of these features include presenter screen features, animation transitions, animation build order, object highlighting, navigation, and playing media.

Desired Features and Automation

The main purpose of the system is to automate as many mundane manually intensive error-prone tasks. With the invention and utility of AI, the system can integrate an AI framework as a third party to aid the users in accomplishing tasks such as researching ideas and explaining code in detail. The system can allow the participant to record mouse or keyboard actions that they can play when presenting code. These actions include navigating to a new source code file, deleting/creating files, source code editor UI system navigation, and interaction among other things.