IDEaL Final Deliverables

Pitch Deck

CS177 Final Pitch Deck

Google Slides with Speaker Notes

 

Individual Self-Reflections

Amrita

Neel

Jin-Hee

Monique

 

Look-and-feel Prototype

Style Tile:

Interactive Demo

Figma Prototype

Design
Looking to popular IDEs with a slick look such as VSCode and Sublime, we stuck with a simplistic IDE layout with just the basics on the screen to start with: the file you’re in, the code you’re writing, the line numbers, and the buttons you need to make stuff run.
We also used popular learning companies such as Khan Academy or Duolingo to motivate our color selection in our style tile, ultimately opting for a mostly black/white/gray/blue palette with touches of green and yellow.
In an IDE, seeing errors is the most important thing, and we didn’t want too much color to take away from that. Thus, most of the screen is dark gray / white depending on the user’s selection of “dark mode” or “light mode.”

Product Branding
Since the learning-focus is what sets us apart from other IDEs, it made sense to heavily emphasize this in our branding: from the product name to what to put on the loading screen as the app was firing up to how we will brand ourselves in pursuit of customers.

 

Implementation Prototype

Video Demo

GitHub

Our process

  • Started by building a CLI tool to parse error messages into simpler, more readable messages
    • Focus on 3-4 of the most common Python/C++ error messages to start
  • Take CLI tool and package into a VSCode extension
  • Use HTML and CSS to add graphics to make the popup more engaging
  • Test in development environment to make sure specific error messages are being parsed correctly

 

Role Prototype

Our insights

  • Error readability can greatly affect a beginner’s motivation level/dedication to continuing CS.
  • On-the-fly conceptual reminders are very helpful, especially because our interviewees liked to fix their code as they go instead of having to go back at the end to fix things.
  • People want fast/“instant” access to conceptual material that would be most helpful to them for their assignment.

Role Prototype Writeup

Our product’s value comes from being a text editor that lets you learn as you go. A typical user could be a CS106A student. When the 106A student starts an assignment using our IDE, they’ll have immediate access to the lectures and course notes relevant to the assignment they’re currently working on. As they begin coding, the IDE will highlight any style issues alongside a suggestion on how to improve it, which allows the user to fix their style in the process, instead of having to go back and potentially getting lost in their own code. Any errors will also be flagged and explained in “readable”, plain English, which lets the user thoroughly understand the mistake they made, and how to avoid repeating that problem. The user has the option of making “sticky notes” to jot down anything they want to remember, such as a mistake they’ve formerly made, or specific syntax they constantly forget, etc.

Weak signals that indicate our product’s value would include some usage of the sticky notes. Although the user may not be using the sticky notes frequently, the fact that they’re utilizing the sticky feature at all indicates that the user does want the option to keep their own notes (in their own words) in addition to the help that the IDE provides. Strong signals that indicate value include high retention in the IDE (e.g., not frequently clicking out or for long periods of time) since the user no longer has to heavily google the meaning of error messages and less repeated style issues, which means that the user is actively reading the style suggestions and correctly implementing the advice as they move forward. After all of our assumption and experience prototype testing, the features we will include in our GTM strategy include 1) readable error messages, 2) style suggestions, 3) relevant conceptual notes, 4) sticky note features. These four key features were proven to make the IDE valuable for the user, as they effectively assist the user’s learning without being overwhelming.

One-Pager

Link to our Google doc

IDEaL

An educational IDE for all programming Learners

Our Opportunity

Learning to code can be an overwhelming, stressful experience for new learners. Building this increasingly sought-after skill involves wading through a sea of domain-specific jargon, grasping challenging programming techniques and design patterns, and rooting out seemingly undetectable bugs. And these difficulties are compounded by IDEs on the market today, which have steep learning curves and are not tailored for novices. Even using these IDEs, many new coding students find the process of debugging and understanding opaque error messages challenging, time-consuming, and demotivating. Those that persevere through these issues can pick up bad habits in code style and efficiency that make writing more complicated pieces of code more challenging later on, and, as a novice, it can be difficult to identify underlying misconceptions and find relevant resources to remedy them. 

 

Benefits We Offer – A Student’s Perspective

Our solution aims to make the process of learning to code less overwhelming, providing students with an understandable, encouraging, and fun way to program. A potential student user might say the following about our IDE:

  • It is easier and less intimidating to start coding
  • I can learn as I go, diving into topics I have trouble with instead of being inundated with information
  • The tailored feedback IDEaL provides helps me write cleaner, more beautiful code
  • IDEaL helps me spend less time debugging
  • Understanding errors I face when programming is so much easier 
  • The tool is simple and easy to use for novice programmers like me
  • IDEaL integrates with my class, so I can finish my assignments more quickly with more support

Mock Customer Case Study

  • Let’s say Z is a student in CS106B. On the first week of classes, Z would download IDEAL as their IDE and load in the CS106B-specific packages into IDEAL and gets to coding up their first assignment. 
  • The first time that Z makes a style error, IDEAL flags it, provides a detailed message describing the issue, and then logs it for future use. 
  • Then, Z can see that error and how many times it has been flagged within a dashboard on the front page of IDEAL.
  • Now, we have a student Y who is also a student in CS106B. To provide for A/B testing, we have Y download the standard Qt Creator IDE for the course, and get started on the first assignment with the CS106B-specific packages installed. 
  • When Y makes a style error, they would need to wait until their scheduled grading session with their section leader before they are told about it. 
  • We chat with both Y and Z, who are on the same curriculum and in the same course, to see which IDE worked better for them and what grade they ended up getting on the first assignment. 
  • The above steps will help us make a determination about if IDEAL does help student learning and increase student outcomes.

Areas of Uncertainty

  1. Market fit: will we be able to compete with Sublime, VSCode, etc. How are we going to differentiate ourselves?
  2. Viability for university clients : Will this be something that university lecturers will go for and find valuable? If they do, how can we get the onboarding cost to be minimal enough that course staff can pivot to IDEAL and get their students to be on board too?
  3. Tech stack: a long-term vision of this tooling would be getting it integrated within a code analyzer like clangd, which would require a fair bit of open-source contribution 

Plan to Explore Areas of Uncertainty

[Neel with 2 lecturers in the Stanford CS department]

  1. Performing more interviews with students and lecturers alike to make sure that we’re including features that lead to a high differentiability and fit
  2. Going and talking to lecturers to see what they think of the idea / product. We would want to find out what changes we would need to make to our product, as well as what changes they forecast would need to be made to curriculums to better fit the product. 
    1. It would also be interesting to learn about what technologies / improvements have worked best for them in their career to this point and at what point they knew they needed to make a change of that nature.
  3. Researching the landscape of code analyzers and linters to see what the best route of action would be as far as getting our tooling integrated is

 

Prior Research – What We Know

[Jin-Hee with a Stanford CS student.]

 

From interviewing the people learning to code, we learned… 

  • Computer science as a discipline feels daunting and inaccessible.
  • You could stare at the same line of an error message for a long time, just trying to figure out what the jargon means.
  • There is no popular, standardized way to fix style as you code, so it’s often an afterthought or an unknown to new coders.
  • The process of reviewing a key concept while coding can feel scattered.

 

From interviewing the people teaching others how to code, we learned… 

  • Section leaders find themselves repeating the same exact style comments to multiple students throughout the grading process.
  • Many students wait hours in office hours just to help with an IDE setup question.
  • Section time that is spent answering questions on style or formatting could be better used, especially used for more conceptual review / problem-solving.

Leading Signals

We know that things are working if we observe… 

  • Increasing revenue / deals with individuals and institutions;
  • Educators do not have to repeat the same exact style comments on all assignments;
  • Users do not spend more than 4 hours at a time on the IDE – avoiding overwhelm;
  • People have feedback to give us.

 

We know that things are not working if we observe… 

  • A stagnant user base, not attracting new individual users;
  • Students use other IDEs to complete assignments;
  • Partnered institutions / educators spend the same amount or more time explaining IDE messages / giving style feedback.

Alternative Options

  1. A plug-in that we could create and sell to an existing, popular IDE (or IDEs).
  • Benefits: less ground-up development work, reach a wider user base since popular IDEs already have existing users.
  • Drawbacks: business complications between IDE companies and education partners, different builds for different IDEs could be tedious, could have less control in our messaging / content.

 

  1. A learning hub / platform that educators could use directly.
  • Benefits: can easily make it more comprehensive and organized, keeps the conceptual / learning component separate and easy to compartmentalize.
  • Drawbacks: many already exist (super red ocean: Geeks4Geeks, Khan Academy, XForDummies), making it difficult to get traction; could be a duplicate to course websites, making it difficult to enter into partnerships with universities / learning institutions.

Why Now

Even amid our recession and big tech layoffs, people are still learning to code—especially at Stanford, whose 106 population is our initial target user base. Every fall quarter, Stanford CS106A/B enrollment continues to grow and hit a greater size than before. Even Stanford students in other fields are still encouraged to at least take CS106A for a competitive edge in their career. Our IDE will always have and fulfill the opportunity to serve a large group of people that are trying to learn how to program.

 

Technologies Involved

Our MVP takes the form of an extension for the population text editor VSCode. To create this, we leveraged VSCode’s Extension API in TypeScript as well as Python and shell scripting for our underlying logic. This implementation prototype focuses on our understandable errors feature, catching errors in terminal output and providing real-time translations into understandable, jargon-free English-language messages.

For our final product, we plan to implement a full standalone IDE. This will include syntax highlighting, autocompletion, and style feedback, and will thereby involve lexical analysis and parsing of students’ written code as part of our implementation. We would also like to integrate with gdb and the lldb API to create an interactive, beginner-friendly debugger. We will leverage an NLP generative model akin to OpenAI GPT-3 trained on student code to provide smarter feedback and suggestions based on past errors and common coding misconceptions.

 

Looking Forward – Time Frame and Deliverables

The first 1.5 months were spent researching existing IDEs, building and testing experience prototypes, building low-fi prototypes, and coding our very basic functioning product. Within three months, we should have our first iteration of our “fully fleshed” product and begin to conduct further user testing. In one to three quarters, we expect to partner with an academic institution / class (e.g. CS106A). Within the next three years, we plan to expand our sales opportunities with at least 3-5 other universities/academic institutions.

 

 

 

Avatar

About the author