The IDE for Education (ide4edu) project has made some progress over these last few months with the help of some undergraduate students. Most of the effort has been around making Eclipse just a little easier to use during those first few months of learning.
For the first time user, the flexibility of the JDT is more than is required. Initially, we forked bits of the JDT code and tweaked it to suit our needs. In a relatively short period of time, it became clear that we needed to be a little more radical with our efforts. Forking just isn’t the right way to go. For starters, we ended up with a lot of code that accesses non-public APIs. More important, however, it was just really hard to make significant changes to things like wizards. So, we completely reimplemented the New Java Project and New Class wizards.
Here’s the New Class wizard:
Given our audience, we decided that we could make some assumptions on the user’s behalf. We ask only for the information that we actually need. At this point, the appearance of the wizard is dynamic. The very first time the user asks for it, they are only asked for the name of the class (current implementation also asks for a package, but we’ll probably hide that as well). We assume that, if the workspace is empty (i.e. they’ve never actually created a project of their own), than they don’t need to be bothered to understand things like projects. When they create their first class, we build the first project automatically. As the student’s understanding increases (as determined by the state of the workspace), additional fields are exposed.
When the “Project Name” field is available, the user is free to type whatever name they want there. If the name they type is for a project that doesn’t exist, the project is created. Automatically created projects are built using what we believe are reasonable defaults for students in their first few weeks and months of education.
We’re trying really hard to keep these wizards simple. The dynamic nature of the wizards has been the source of some debate. Is it correct to change the appearance of the wizard? We’ve discussed providing some mechanism to let the user know that the change has occurred. We’ve also talked about making a more general mechanism for determining the competency level of the student so that we can better tune more aspects of the delivery.
One thing that fell out of this implementation is a clear separation between the user interface and the underlying behaviour. This is implemented in two layers: there is a NewJavaClassConstructor type that knows how to actually build a class (and project if necessary), and there is a corresponding wizard that knows how to use the NewJavaClassConstructor to do the the heavy lifting. This separation should allow us to leverage the constructor behaviour in other contexts (I dream of coming up with an entirely different create user interface paradigm).
We’re still pretty far away from a proper release. We have a lot of testing to do, still have a lot more code using non-public APIs than I’m comfortable with, have some work going on to introduce a Scheme environment for students, and are hopeful for some Prolog support. In the meantime, I’m turning my attention to fixing the build (basing it on Athena) so that we can do a better job of getting what we have into the hands of more students to get more feedback.
Hey students and mentors, the Google Summer of Code 2010 has been announced. Keep ide4edu in mind when you’re proposing your summer project!
