Yesterday I had a break from the sun and a few hours spare and wrote a little program I have been wanting to write for a while. First though, a little back story.
A little while back, Aq and I did a Shot Of Jaq shot about how back in the good ol’ days computers used to make programming more accessible to kids. The basic gist of the shot was that when you bought a Commodore 64 or Spectrum, access to the BASIC language was up-front, and your computer came with a manual that taught you how to write programs in BASIC. This was great for kids and others who wanted to explore their computers. It introduced them to programming, and taught them that you could make the computer do all manner of different things if you learned this simple language, while all the time teaching them about logic and semantics. This was an incredible thrill for me when I was such an ankle-biter: I felt this tremendous liberation that I could write any kind of program I wanted. In a nutshell, it sowed the seeds of opportunistic development in my mind.
The Shot Of Jaq shot really got me thinking about how accessible to programming computers are for kids today. I did a quick scoot around to research what software was available, and there seemed to be limited options that would be suitable for young kids. As such, I decided that this could be a fun little project for me blow a few hours of free time on. And thus…PyJunior was born.
PyJunior is a little program that has a very focused goal: to provide a simple environment for kids to play with Python. Python is a beautiful language and one ideally suited for kids and others to get started with programming. My goal was to make something incredibly simple and very focused on simple programming tasks. My intention here is not to build a full programming environment with access to Glade, PyGTK documentation and testing tools: that is simply too much. It was instead to allow a kid to write instructions in a program, press a button and watch it work.
As part of focusing my design on simplicity, I had a few core concepts in mind when writing PyJunior:
- No complex projects – multi-file projects are confusing and beyond the scope of PyJunior. The focus here is on single programs.
- No saving – I don’t want kids to have to think about saving when writing their programs. They should focus on writing code and running it, not remembering to save.
No concept of files – when learning about programming, each unnecessary step is likely to confuse them and lose their interest. They should not need to think about creating a
.pyfile and executing it, and instead just have the concept of creating and loading programs.
- Lean user interface – too many buttons and menus are likely to confuse the user, so the interface needs to be lean and focused on it’s core functions.
- Kid-friendly user interface – kids that are young are new to using mice, so the buttons need to be nice and big and clickable. The buttons also need to be discoverable: we can’t assume they know what the icons mean, so they need to be labeled.
Let me show how it works. This is the main interface:
The interface is simple. There is an area where you can type in code in at the top (which is syntax highlighted to make it easier to understand), and below it is where the output of the program is displayed. At the top is a toolbar that I have deliberately made nice and big and easy to click for kids who are new to using a mouse. When they want to run the code they have typed in, they click the Run button. This will automatically save the file, run it and display the output in the black area at the bottom.
The interface makes teaching kids how to write programs easy: they write in the instructions, press the Run button and see the results of their instructions in the black area at the bottom.
If the user wants to create or load a new program, they click on the My Programs button and see this:
In designing PyJunior, I was conscious to make a one stop shop for dealing with new and existing programs: I didn’t want to have separate dialog boxes for new and existing programs as I felt his would clutter the interface (I want to keep that toolbar lean) and confuse the user. I was also really keen to not simply use a file picker for creating and loading programs: kids are likely to get confused by it and pick the wrong files, accidentally delete things etc. As such, I decided to put the program creation and loading in one dialog, and make it as simple as possible.
To create a new program, I wanted to make it as simple as typing in a descriptive name for the program as opposed to a filename. When the user types this in, PyJunior creates the file and immediately loads it in the main editor as shown above. This will also add the program to the list of existing program that can be loaded (shown at the bottom of the My Programs dialog box). To load a program, a list of already created programs in shown and the user can double-click it to load it in the editor. This entire process entirely bypasses the concept of files and directories: the focus is on descriptive names that refer to progams as opposed to filenames.
…and that is pretty much it. I am pretty pleased with my few hours of hacking, and I think it provides a good base for future development. I am still on vacation so there is no code uploaded or packages built yet, but I will have this arranged soon. Before I wrap up though, I want to talk about one more thing which is critical to the success of PyJunior: the Help button.
I feel PyJunior provides a great way of getting kids started with working with programs, but it doesn’t help them learn Python. What we really need now is a simple set of documentation that teaches kids in a very kid-friendly way how Python works. I would ideally like the user to click on the nice big Help toolbar button and it shows a standard GNOME help window with a tutorial about how to use Python. This documentation needs to be written and designed for kids: it needs to be visual and easy to read, and explain core elements of Python such as variables, lists, dictionaries, input, conditional statements and loops. So this is where I would like to focus the next steps of PyJunior, but I really need help with this: would anyone be interested in helping?