One the things I did deliberately with Class Viewer--which is why open source is such a nice paradigm as you can try new things--is get away from the "File", "Edit", "View" type of menu at the top. So I have "Help" first, and then "Links", and for when it's not in applet mode, "ClassPath".
To me that's just a more natural way for the menu to go, and I like to think that I managed a fairly decent design for a program I long thought of as a prototype.
The design of Class Viewer is meant to lead you to using it intuitively, without needing a lot of instruction or lots of menu items, as you can type in a class, and then just use the the mouse, and get all the way to javadocs to a particular method.
I decided to call it a User Enabling Interface, or UEI.
The way Class Viewer is designed, there just isn't much configuration, and it gets all of its changeable information, like where packages are, or what browser you're using, from packagedirectory.xml, so the program is fairly static.
I like to say that as long as the format for getting javadocs doesn't change, and the Reflections api isn't broken with previous versions, Class Viewer can be used indefinitely, as you can simply change the xml file, which means that I could stop development now, and feel confident that several years from now, Class Viewer could still be used.
My design focus is on an easy to use design that doesn't force me to keep fiddling with things to do something, and which doesn't make me go through a lot of options, as I think a proper design, for a properly encapsulated problem solution, will not require a lot of effort just figuring out how to get it all to work.
If you need a lot of options, I think you need a separate module or another program that might be called by your app (and I'm considering what else to add to Class Viewer where it would call another program), versus forcing people to spend time understanding a particular design.
James
No comments:
Post a Comment