The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Multiple Forms or One Form per page?

Some of the guys on my current project are advocating the combination of all form input on our html pages into a single form per page.

For example:
There is a small form that lets the user change their preferences. There is a small form that lets the user start a new search. There is a main form that lets the user edit address data.

In their new scheme all of these forms would be combined to one form. When the user hits submit we would have a master controller responsible for determining which form was actually submitted and then processing the request. After the request is completed the system would return a form that still contains data from other half-completed "forms" (of which the user could then complete and resubmit).

My thoughts are that combining forms in this manner is overly complicated and not worth the trouble. Does anyone else have experiences with this problem?
NathanJ Send private email
Friday, July 14, 2006
I like to split things up. Keeps things much simpler.
Friday, July 14, 2006
One issue I've run into is: if you're already showing all these forms on one page, you need some controller that can pre-populate them all. So already you have a controller that's aware of all the forms. At this point it sometimes becomes simpler to just submit them all to that same controller. Maybe that's what your co-workers are thinking?

This is especially important if, for example, you submit a form and there are errors. You'll want to return to the page and display the errors, but you'll probably want to keep the existing values of the other forms intact.
Friday, July 14, 2006
I'd have to see it to be sure, but it sounds like bad design to me. If I set a preference and put something in the search field and then hit submit, what would happen? Would the preference be set or the search executed?
Friday, July 14, 2006
from your statement, you already have to deal with the postback, so I would follow 2 rules:

- Simple Responsibility Priciple (aka "do one thing, do it well")

- Everything should be as simple as possible, but not simpler (Albert Einstein)
Another Anonymous Coward
Friday, July 14, 2006
If everything's one big form, you'll be sending a lot of idle, unnecessary data to your master controller. That to me sounds like a design flaw.
Friday, July 14, 2006
Putting aside "how?" for a moment, I'm wondering "why?" Of course, I can't say for sure without seeing it, but it sounds like a usability nightmare.
Friday, July 14, 2006
Only the main form gets prepopulated. All of the other forms are blank and only used if the user puts stuff in them and hits submit.

Each "sub-form" would still have a seperate submit button. The dispatcher would be in charge of figuring out which button was pressed and handling the sub-form's request.
NathanJ Send private email
Friday, July 14, 2006
I'm interested in hearing how the dispatcher will determine which Submit button was pressed. Is it based on which subform contains data?
Friday, July 14, 2006
Only the Submit button that was pressed would be sent to the server (like checkboxes) so if they have different names or values, that part is easy.

It's a bad idea though. There is no benefit in coding or usability, and it's not the web standard.

Tell your developer no, he's trying to be too abstract and/or just read the wrong book on patterns.
PHDude Send private email
Friday, July 14, 2006
That's pretty easy. The decision is driven by your requirements.

If you do need to show all populated values after the request then you go with one form. If you don't need then multiple forms would be easier. If requirements aren't defined then go with what is simpler. If your guys love programming so much that they would dive into one form - well let them go if they have time.

Denis Krukovsky
Denis Krukovsky Send private email
Friday, July 14, 2006
Do a usability study, with actual users. You can do an A/B test if you like. This doesn't cost much and will settle the argument.
Robby Slaughter Send private email
Friday, July 14, 2006
To corrupt the Victoria’s Secret slogan, what is simple?  From the user’s perspective, a web page with a single short form on it sounds simple, but is it simple to have three web pages of a form a piece plus a “root” menu page to get to each one of the three pages? If the forms are dead simple (e.g., three controls each or less) and you can fit them all “above the fold” (within about 570 pixels vertical), then it’s probably simpler and faster for the user to put them all on one page rather than three separate pages.

You could of course compromise: put two frequently used forms on the root page, and link to a third rarely used form. The page the user uses a lot is simplified and, while one page is harder to get to, it is used infrequently so that has little impact.

Developers: Working hard so users don’t have to.
Michael Zuschlag Send private email
Monday, July 17, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz