Generally multi-window applications that pop up new windows
all the time are somewhat disconcerting. However, in this case, forms
are like separate pieces of paper, so having each one be a separate
window seems livable, and maybe even preferable. However, the several
`tiny' windows that currently pop up are not well designed. The form
system is not xscreensaver; it doesn't need to have a small footprint,
that's what iconization is for. Also, the design of the three buttons,
followed by the appropriate menus, is very modal; we should try and
present the user with many options at once. Thus, menus. However, the
main form display window will not be displaying the actual forms. So
what will there be in it?

	Currently, there's a list of all form types, a list of all
users, a list of all forms belonging to a given type, and a list of
all forms belonging to a given user. This is a lot of information to
have on the screen at once, and it's only really useful for this toy
form description. For real use, we're going to need to change a bunch
of things about the form system.

1) Real users are going to want to stick their form routing systems in
different places, rather than /mit/forms/db. For this, I propose we
standardize a directory tree for storing the forms (does the current
directory tree need any work? db/classes and db/owners?), and use
environment variables (gasp!) to set the default location of the
directory tree. Some questions: Should a form currently owned by
person X be readable by person Y? (I think the answer should be, `Not
necessarily.') Should it be stored in person X's directory tree? (I
think `yes.') Is an architecture like this good?
All form definitions are stored in
	$FORMDEFINITIONS/Forms/name-of-form
and person X's owned forms are stored in
	/mit/X/Forms/form-id-#
The other possibility, of course, is to stick with the current
directory tree. However, we MUST make the location of the top of the
tree, at least, user-settable.

2) Users are probably going to want to `narrow their focus' about the
forms they want to see, too. Perhaps a file like
	/mit/bobby/Forms/.preferences
is warranted, containing things like a list of forms Bobby is
interested in (perhaps Bobby only wants to see, by default, forms of
the Acquire-Book variety rather than
Shove-Book-Up-Harvard-Libraries'-Butt), what form type is created by
default when Bobby hits Control-N (or something similar), how the
form system initially configures itself, etc. We could use X
resources, but if we ever built a smart tty client, it would come back
to haunt us.

3) The current form numbering system leaves something to be desired.
At the very least, each form should have, in addition to the
number, some sort of internal descriptive field which is displayed in
addition to the form number in any lists. Perhaps a new slot in the
form description language (alterable by the preferences file!),
`DESCRIPTION' or something, which pretty much tells smart clients to
display in any lists of forms, that field's value in addition to the
form number. (That shouldn't be all that hard to implement, and it
would be quite helpful!) Also, I think the form numbers should be
numbered sequentially from 1 for each form type, rather than
time-stamped, just because the current 8-digit numbers or whatever
have no relation to reality.

Okay, so what should the new system display by default? The initial
screen, the one that is always visible, should have:

1) A menu bar. Contained in it should be an About item, a Quit item,
items for altering your preferences and saving them, something to
reread all the information on the screen, something to create a new
form of the given type, something to alter the selected form, etc.

2) A list of types of forms the user is interested in. (Should types
of forms which the user has none of be grayed out? Quibble, quibble.)

3) A list of forms the user owns, of the currently selected type(s).
You should be able to select more than one type at once, so that, if
desired, you can see all the forms you own.

Probably these last two would be contained in a PanedWindow of some sort.

When a form is selected for editing, the form displayed should
contain, in addition to the form itself,

1) A menu bar along the top, containing things you can do to the form.

2) The action buttons, the form ID, and other information about the form.

The actions should be separated visually from the form itself, unlike
currently. I have some interesting visual ideas for the way the form
itself should look, but this isn't the place.

Finally, we come to the Big One:

MOTIF OR ATHENA WIDGETS??!

I vote for Motif, because the system will be prettier, easier to
program, happier, spoogier, etc. The disadvantage, of course, is
speed. We can argue about this religious issue later.