Post a Comment On: Only Python

Since the release of my little app, Lightning Compiler :-), I have been confronted with design issues that, I imagine, many of those reading this blog face often in the course of their daily work. However, since I only program as a hobby, the issue of ui design is essentially all new to me. Going through the experience for a second time (the first was when I designed rur-ple) has given me a better appreciation of Joel Spolsky writings on the subject.

Lightning Compiler was originally meant as a teaching tool embedded in rur-ple. As such, it was very simple by design. Since I "extracted" it from rur-ple to become a stand-alone tool, I have been faced with the temptation of adding various features (creeping featuritis?), following users' comments (3!), especially when they had themselves made some modifications that they found useful.

I don't want Lightning Compiler to become a bloated app. ;-) Actually, as anybody that has looked at it would know, there is very little danger of this happening anytime soon - at least, by the usual understanding of what a bloated app is. Still, I want to keep it simple and true to its orginal purpose. I would be very interested in hearing about other programmers' comments on my thoughts on the issue of design of an app like Lightning Compiler (L.C. for short), especially given my relative lack of experience on the subject. To provide a starting point to the discussion, here are a few thoughts on the subject.

L.C. is meant as a "quick and dirty" little app, useful to test some programs, usually short ones but that would be too long to type (and re-type) at the interpreter prompt. The idea is: type a program, press a button to execute, look at the output; make some changes and repeat the process.L.C. is meant to add a "nice" user interface for input() and raw_input() commands when needed. This is its one "unique" feature as far as I know.L.C. can also be use to run (and modify, and run again...) longer programs obtained from elsewhere - like, for instance, the Python Cookbook. The idea is to be able to cut-and-paste a code sample and run it with as little fuss as possible.L.C. should be as simple as possible to be useful to do this - but no simpler.With these objectives in mind, here are some of the design features with the motivation for each of them:
L.C. is a gui app that is meant to be lauched either from a terminal window or (under Windows XP, which I use - sorry to Linux and Mac users;-) by double-clicking on it. Still, I keep a terminal window present so that error messages from running L.C. itself can be read and captured. (This was especially useful in the original writing of L.C.)L.C has two basic windows: an editor window and an output window; print and error statements are redirected to the output window when running a program (and redirected back to the default terminal window afterwards, so that error messages from running L.C. are captured separately).L.C. has no menus, only buttons. Each option/operation is thus meant to be always visible at all time. Since nothing is hidden, the number of options has to be small ;-)
L.C.'s buttons are simple labeled buttons (no fancy image); the idea is to keep it in a single file, as small as possible.Button labels are only in English. Well, this is of course easily changed by an individual programmer; this is a programmer's tool after all.Each action that can be performed by pressing a button can also be performed by a key combination. This is to allow "power users" to use it without their hands leaving the keyboard. From what I have read, this is considered nearly essential by *nix power users ;-)Possibility to hide the output window, giving more space to the editing window (to see more code at once); when hiding the output window, the amount of screen-space it occupies (after possible adjustment by the user) is remembered.
Focus in the editor window at the start; ready to type and run :-)Default size of output window just large enough that all "help text" can be displayed at once in it... but no longer.Access to the interpreter, through a tabbed interface. This should be especially useful for finding information about modules with dir() or help()
(New) If some text is selected, only that text is executed - but a warning is added in the output window ... especially in case the selected text is not visible in the Editor window because of scrolling...(New) Go to line number feature; should be useful when an error message is seen in the output window.The text from the output window is NOT cleared each time a new program execution (run) occurs; I know that one user changed that default so that his output window is cleared each time. My reasoning is that a user should be able to run the program, change a parameter, run it again, and be able to compare the results of each run. It is easy enough to clear the output after all (ctrl-l or pressing a button).No "find" feature. I've debated about this one... I looked at the wxPython demo and realised that, to do this properly requires more than a few lines of code... Furthermore, if one runs a program and gets an error message, only the line number (with the new "go to" feature) is really needed. I'm still debating...
NO find-and-replace feature. This is something that is useful in a full-fledge editor or IDE, but seems to be an overkill for an app of this kind.Open and save file; this should be self-explanatory. No "save as"; can be easily done within save - actually "save" is really a "save as". ;-)Help button; just as a reminder that it is available.L.C. has no provisions for running programs that expect some arguments. I believe that if this can not be simulated with an added "if __name__ == '__main__" block, then you should use a different tool to work with.
That's it. What are your thoughts? Is there anything that I should have done differently?