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?
