MILESTONE 2: Write-Up Component
Project Concept
IDEaL aims to stay true to its name – an IDE (integrated development environment) for all Learners. All four members of our team have been or currently are involved with computer science education, primarily as a teaching assistant role. Therefore, we have worn both the student and the teacher hats when thinking about learning CS. As the folks grading the programming assignments, we’ve found ourselves having to repeat the same kinds of style notes over and over again, and hearing concerns from students that it’s “just too hard” to start coding in their class’ suggested IDE.
IDEaL makes the coding process easier for non-technical and beginner coders who are in the learning process, offering everything from style feedback to more understandable language to access to conceptual review. We understand how frustrating and intimidating it can be to step into the tech and CS world, and are building IDEaL to make this learning curve less bumpy than it is today.
Value Proposition
Our value proposition was written with our interviewee responses in mind; we found how difficult it was to strike the balance between beginner-friendliness and personalizable/complex functionality, so we wanted to offer something specifically for the newbies, not something that the newbies would just “have to get used to.”
Why is our proposition correct? For starters, all of our interviewees – even the ones who felt like computer science came naturally to them – expressed some degree of frustration with learning how to code in their first couple of IDEs. Particularly, they feel angry when they spend hours trying to decode a syntax error that doesn’t allow their code to build, only to find that it was a tiny fix and could have been resolved within a minute.
Quarter after quarter in Stanford’s CS106A and 106B classes, dozens of students come to office hours just for help on interacting with the IDE. This means that it’s not uncommon for a student to wait 2+ hours in the queue for office hours, just for help translating an unfriendly error message in Qt Creator. In fact, CS106B has created an office hours at the beginning of the quarter dedicated specifically to how to set up and interact with your IDE. The fact that these office hours requests happen consistently are another indicator that there is value in a learner-focused IDE.
MVP Choices and Motivation
- Main focus: beginner-friendly, plain English error messages
- Difficulty debugging and understanding complex error messages was a common theme across the board in initial needfinding interviews
- Understandable error messages were consistently placed under features to be included soon in our participatory roadmap
- Beginner-friendly error descriptions are a key differentiating feature not found in other IDE offerings
- Additional differentiating features
- Style and conceptual error recognition
- Sticky notes to track key concepts and common errors
- Links to relevant conceptual resources
- Implementation: Sublime plugin
- Rather than build out a full IDE as our MVP, we instead focus implement our main features as a plugin in the Sublime IDE
- Enables us to develop and test key components of our solution without the implementation overhead of a full IDE
Project Goal (how users’ lives are changed by the product)
As covered in our project concept, the goal of IDEaL is to make the coding process easier for people that are starting to learn how to code. Many people feel that there’s a high barrier to entry in computer science. By creating a user-friendly, non-overwhelming, readable, and educational IDE, we are removing one of the many hoops that people have to jump through to feel like they’re capable of continuing. Features such as highlighting style errors and providing a suggestion or optional correction will allow the user to catch their mistake in “real-time” and immediately see how they could fix it, instead of potentially struggling to find where the error occurred once they ran their code. Integrating relevant lecture material (videos, lecture slides, notes) into the IDE heavily reinforces what the student is learning, and also means that the student won’t have to spend a lot of time merely trying to look for the correct learning material to review.
Assumptions We’re Still Worried About
The main assumptions we’re still worried about are the ones we haven’t gotten around to testing. Ideally, we would be testing all of our key assumptions which include:
-
- “The social aspect of learning how to code is NOT a top priority in a learning-based IDE.”
- “Students would like to learn programming with lectures as-they-go while coding, rather than separately from the IDE experience.”
- “Style and conceptual errors matter to new CS learners as much as functionality.”
- “People know how to set up an IDE / tools.”
- “Many programming learners face overwhelm with heavyweight existing IDEs.”
- “Beginners are interested in optimizing code efficiency and runtime.”
Although we haven’t tested these assumptions, we’re still planning to build and incorporate features that address these assumptions. Without testing them, our concern is not prioritizing the most important things.
Experience Prototyping and Results
Our experience prototype was based on the guiding assumption: We believe that people who are learning to code appreciate simplistic, “plain English” phrasing in their error messages / suggestions. We modeled our prototype by providing interviewees with 3 different C++ error messages, all targeting different errors. We first showed them actual C++ error messages as generated by clang and the Stanford library, then we showed them more simplified and more targeted error messages that we generated ourselves and would want to include in our final product for ideal. Since concise and simple error messages are a core feature of our text editor, we wanted to see how much value the simplified versions would add. We also wanted our interviewees to get a real experience with seeing C++ error messages and be able to monitor / gauge how they responded to the old vs. new model. These interviews turned out well, and we were able to gain good insights from the two testers. Tester 1 said they were able to get a much clearer sense of where the specific issue in the program lied, and had a much easier time debugging from there. Tester 2 is a more experienced programmer, and thought that while the first error message was verbose there was more information presented that could be helpful for context. Tester 2 did say that the specific error messages for invalid types was great since those errors can be particularly tricky to parse, especially as students haven’t learned about pointers yet.
Future Experience Prototypes
…would test the following assumptions:
- People know how to set up an IDE and associated tools
- This assumption affects a user’s first interaction with our IDE – based on our needfinding, new learners can often be intimidated and discouraged by a long and unwieldy setup process for IDEs
- Students would like to learn programming with lectures as-they-go while coding, rather than separately from the IDE experience.
- This tests the value of integrated lessons as a differentiating feature in our IDE. If students do not enjoy learning and watching lectures during the coding process, this would both call into question the need for this feature and make it more challenging to pursue a prosumer model where universities can integrate resources with their IDE to provide school-specific support
- Style and conceptual errors matter to learners as much as functionality
- This tests another key differentiator of our IDE from other offerings. Overcoming misconceptions in programming concepts and style are key to growth as a programmer, and this experience prototype would help us evaluate where our target market values that long-term growth when they first begin learning to code
- The social aspect of learning how to code is NOT a top priority in a learning-based IDE
- The main features of our IDE primarily view learning to code as an individual activity, and this experience prototype helps confirm our hypothesis that social features are not initially valued by new coders
Immediate Next Steps
We think building a prototype experience for our other key feature of style error deduction would be the next step. Style errors are ubiquitous in CS106 code, and lead to section leaders having to repeat comments and deductions across multiple assignments. We want to incorporate style feedback right at the IDE level so that students get targeted advice and help to fix those issues.
Product Viability
Based on the experience prototypes we have planned out and the results of our tests with potential users, our product is viable. Across both testers, we saw positive feedback for plain-English error messaging, observing results on how well students were able to debug using these new messages that showed improvement with our new error beginner-friendly messages over those presented by a standard IDE. These results, along with our competitive analysis, support our hypothesis that this error messaging would be a valuable primary feature to include in an MVP for our IDE tailored toward students.
Advice from Reviewers
We would really appreciate advice on a few key areas as we move forward into further assumption testing and prototyping:
- Selecting features to translate to our Sublime plugin MVP
- Based on our experience prototypes, we’d like a bit of direction on which features might be best to translate into our MVP, as we’re trying to balance between having the minimum number of necessary features while still providing value to students who would use a Sublime plugin
- Prosumer business model
- We’d like to work through how best to implement a prosumer business model for our case and how to differentiate university-specific offerings from a free IDE for individual students. We are currently considering course integration as a differentiator for university customers; for instance, Stanford University would be able to integrate CS 106 resources, lectures, and style tips as well as assignments into their tailored offering through our IDE, while individual students would not have this option. In particular, we’d appreciate guidance on how best to define the criteria needed to convince a university to take on a tailored offering (i.e. what percentage of students need to be using the IDE and/or what other differentiating features would we need to include).
Diagrams (All Available in Durand)
BMC
VPC
Participatory Roadmap
Competitive Landscape
Additional analysis available here.
User Storymapping
Individual assumptions available here.
