Although some programmers prefer to edit their code using a text editor like emacs or vi and run their compiler from the command line, a novice programmer is likely to prefer a more "friendly" interface. To this end, an Integrated Development Environment should be provided for Kenya.
There are many IDEs available for developing programs in languages such as Java, C, C++, Visual Basic ... They all have many different features, but tend to share a few common key elements:
Environments like Microsoft's Visual Studio[19] and Sun's Forte[21] offer many other features like class wizards and graphical resource or user interface editors. These more advanced features are likely to be confusing for the novice programmer. It would probably be better if an IDE targeted particularly at new programmers had only the essential features that are necessary to write, compile, debug and run a program without any other, potentially confusing, bells and whistles.
When the JMac[4] system, which was mentioned in a previous section, was developed, the main goal of the project was to produce a good IDE. It was originally my intention to use this IDE for Kenya, simply plugging in the code relevant to parsing and translating the Kenya language where previously the code for the JMac language was. However, after spending some time analysing the code for the JMac IDE. I felt that it would probably be easier to write my own graphical interface from scratch, as it was difficult to work out exactly how the JMac IDE code worked. This was not because the code was bad. The large number of different classes and the fact that the Graphical User Interfaces is event driven, rather than following a step by step procedural execution, (so there is no real start or end to the program) make it hard to analyse. Also, the JMac IDE had some features which I thought were unnecessary, such as a class wizard. By designing my own IDE I could provide exactly the features that I wanted.
I wanted to keep the IDE for Kenya as simple as possible. The main features that are required are:
A lot of existing IDE's (and other types of software) contain a large number of features. The way in which people learn new pieces of software tends not to be by reading the manual, but by trying things out and exploring the software. Because of this, some of the features of a piece of software are likely never to be discovered by users if they are hidden inside a number of levels of menus or option dialogs. There is a compromise to be reached, trading off the ease with which a user can find features against the possibility of presenting them with too much information and too many options, causing them to become confused or daunted by the application's interface. Jeff Raskin discusses such issues at length in his book The Humane Interface[21].
In the design of the Kenya system, I have tried not to include features which are unessential, and to only provide one way of doing everything. ( Larry Wall, the inventor of Perl[22] has a famous adage "There's always more than one way to do it". Perl is a notoriously difficult language to master. ) This should make it easier for the user to learn all of the features, and never to find themselves thinking "I wonder if I'm doing this the right way, perhaps another way would be better ...". Having only a relatively small number of operations that the user can perform means that all of the features can be presented on the user interface without it becoming cluttered or confusing.
I designed the interface which is shown below to address these issues. It has been created using components from the Java Swing classes. The user can swap between editing the Kenya or Java versions of their code, which are displayed in tabbed panes. All of the operations available ( opening a file, compiling the code ... ) are given buttons on a tool bar. At the bottom of the window there is a box in which status messages are displayed, giving the status of program compilation etc.
When a program is executed, another window is opened showing the output which it produces. I wanted to keep the execution of the program inside the Kenya system to give a more homogenous feel to development. When developing with something like Sun's JDK for Java, the code is edited in one program, compiled using a command line compiler, and then run either on the console or showing its own windows. This means the programmer has to switch between different windows and tools depending on what they want to do. Although this allows the more advanced programmer to use their own favourite tools for each part of the development process, customising the way that they work, it is less appropriate for a novice. This is the output window, showing the execution of a program. The box at the bottom of the window allows data to be entered for programs that require user interaction.
Although people are less inclined to read manuals than they once were, there is still a requirement for good support documentation and this may more usefully be supplied in the form of online help. Such documentation is particularly valuable in a programming environment, as a language reference can be provided in which programmers can quickly look up syntax etc. A Java developer will be likely to keep a web browser window open on the API documentation page[23] as they work, and programmers working with Microsoft's libraries find the MDSN[24] references invaluable. As the Kenya IDE is targeted toward a specific programming language, such reference material can be provided for access inside the same interface, meaning that a network connection is not necessary to access the documentation. The only disadvantage with this is that any updates made to the documentation will be slow to propagate to users. This is an example of the help window, where users can find references on the system and the language.
