Re: additional HTML+ FORM types (Long) (Steve Waterbury)
Date: Mon, 11 Oct 93 02:23:54 EDT
From: (Steve Waterbury)
Message-id: <>
Subject: Re: additional HTML+ FORM types (Long)

Marc Andreessen writes (off-line):

> next up is multiline text entry
> areas (which will require an alternative form submission method --
> don't want to be packing 10K of text into a URL).

Great!! That one is very important for something I want to do, which 
is basically set up an input form that creates an HTML doc at the 
same time as it sends the parameters out (well I guess you could 
just say it is sending the parameters to another server that is 
putting them into HTML ... and tagging the non-HTML "logical tag" 
items I mentioned).  Is that perhaps a candidate for the 
"alternative form submission method" -- hmm ... guess you would 
have to build a little "server" functionality into the client 
so it could "serve" the HTML back to the query server in the form 
of an HTML document plus parameters (and/or "logical tags"), and 
then have an HTML and logical tag filter in the interface of your 
query server.  

We definitely need multiline entry for some things, but 
perhaps for "input form" apps that create documents or big 
data objects with really large text and graphics and multi-media 
stuff it would be better to have a capability to "attach" files to 
the other stuff being sumitted from the form.  That could be 
along the lines of the "query" or form results creating an HTML 
doc, with in-line images, links, etc.  

This is getting closer and closer to an HTML editor of sorts!  
But that (using a Mosaic form to create an HTML document, rather 
than a free-form HTML editor -- especially for novices) seems 
appropriate for VERY structured types of data objects, such as 
technical reports.  Our applications include, e.g., Failure 
Analysis reports, which contain several well-defined fields like 
"part number", "manufacturer (CAGE Code)" etc., plus the main 
body -- lots of text -- plus photos.  This is pretty typical of 
a lot of engineering publications, for which a certain amount of 
standardization would be very useful....

> Also, since we have option menus, will it be useful to have scrolled
> selection lists in addition?  (Depends on how many things you think
> you want to put in a single set of options, I suppose...)

Incidentally, your option menus look great ... well, I guess and 
option menu is an option menu, but it`s a trip to see one in an 
HTML document!!  As I say, some of our option menus got too big 
(as in off-the-screen!), so we had to make them scrollable selection 
lists.  To tell the truth, I _think_ I would be just as happy with 
a selection list in a separate document window, if that were 
feasible ... i.e., if the inter-window communications weren't too 
hairy.  But it would also be real nice to have the selection list 
widget adjust to the width of the selections so it doesn't take 
so much screen space.  That may be asking a bit much, though!  

You're doing great.  


----- End Included Message -----