Main Issue:
As a web application developer, I am constantly having to design forms where the user must enter 20-80 fields of data. Obviously this would kill any usability but is required for many enterprise based applications. There seems to be few examples in consumer software because of large data sets don't lend itself to good usability.
Solutions I have tried:
I have played with various ways of handling this type of data from single page categorized form elements. to breaking the form up with wizards or accordion panes. There is also always the dreaded "dependant" select box where one selection refreshes another select box which allows the user to further refine their choice.
Questions to the Community:
I am curious what other people's experiences are in dealing with very large forms. Any typical patterns? Tricks? Things that worked and have not worked?
Thanks,
Rob Meidal
Data Entry Patterns aka: Forms
RobertM9 Sep 2008 9:05 AM
xian22 Sep 2008 4:45 PM
QUOTE
Questions to the Community:
I am curious what other people's experiences are in dealing with very large forms. Any typical patterns? Tricks? Things that worked and have not worked?
It's funny you should mention that. We are working on a substantial set of Form patterns internally (based largely on the work summarized in Luke Wroblewski's book), and we hope to publish them later this year.
I'll need to dig back through what we've got so far to see if I have anything practical to suggest regarding the big long form problem.
Amber C.23 Sep 2008 12:04 PM
QUOTE (xian @ Sep 22 2008, 03:45 PM) <{POST_SNAPBACK}>
It's funny you should mention that. We are working on a substantial set of Form patterns internally (based largely on the work summarized in Luke Wroblewski's book), and we hope to publish them later this year.
I'll need to dig back through what we've got so far to see if I have anything practical to suggest regarding the big long form problem.
I am also very interested in seeing this. In developing forms I've had to cut them up into different pages and allow users to come back to finish them. It's kind of like a hectic college application process with that many form elements.
Some Dood24 Sep 2008 9:36 AM
We also deal with a significant amount of forms in our application. In an effort to streamline data entry, we are implementing some long overdue changes, namely making the [Enter] key the trigger for the form's default (primary) action. This decision is supported by the Form pattern, as specified at Welie
My question pertains to forms that include a TEXTAREA; within this input, the default action for the [Enter] key should be a carriage return.
Are there some patterns or guidelines that specify the correct interaction for [Enter] key events on forms containing TEXTAREA fields?
ENTER key is a shortcut for "confirm", submit, save etc.
My question pertains to forms that include a TEXTAREA; within this input, the default action for the [Enter] key should be a carriage return.
Are there some patterns or guidelines that specify the correct interaction for [Enter] key events on forms containing TEXTAREA fields?
Bram Pitoyo25 Sep 2008 2:42 PM
QUOTE (ariel @ Sep 24 2008, 08:36 AM) <{POST_SNAPBACK}>
ENTER key is a shortcut for "confirm", submit, save etc.
My question pertains to forms that include a TEXTAREA; within this input, the default action for the [Enter] key should be a carriage return.
Are there some patterns or guidelines that specify the correct interaction for [Enter] key events on forms containing TEXTAREA fields?
My experience with TEXTAREA is that, sometime, using [Enter] to create paragraphs causes problem when you export to CSV for analysis. Sometimes, [Enter] would be interpreted as "Put this in a new row" and comments would be dissociated with the entry. To encourage user against using [Enter], I break up the form questions and use smaller TEXTAREAs.