Similar to (One to many) to many form?, but less complex I hope

I'm attempting to present a form in which a user can define a number of spectra, each of which includes a species string and a number of gaussians, which are each a set of 3 numbers. There is a maximum number of gaussians, but fewer can be entered.

Currently, I'm considering something like the following:

enter image description here

However, this quickly gets unwieldy when the user has to define more than 1 or two spectra. I'm sure there is a better way to do this, perhaps by limiting the number of fields for gaussians one sees at one time. but I'm not sure how I would present that...

Is there a better way to present this form?

  • What are the possible values that can be entered? Are they always greater than X and smaller than Y? Are the limits not constant but depend on the other fields? How many digits do values have, usually? Commented Nov 5, 2016 at 9:41

2 Answers 2


I am assuming this is a CRUD app.

Since each form group is relatively long, consider allowing the user to create only one species record at a time. This reduces the risk of correcting extensive validation errors. Imagine entering 20 species just to try and figure out which field is in error state. Yuck.

If there are a number of records, show a (searchable?) list of the records first. Allow the user to Create or Edit a one record at a time. Validate the data on submit and handle validation routines with clear messaging.

Data entry is keyboard centric, try to minimize mouse dependency with tab indexes, etc. One (submit) button allows the Enter/Return key to post the data to a server.

Instruct users about keyboard features and verify with them the experience is effective and efficient.

Things that might be missing from your layout: instructions, input types, labels, buttons, client/server validation.


I'm not entirely clear on the content necessary for input, but if you have a database that you would enable you to make the fields dynamic, that would certainly be more helpful. And if the idea is for users to help fill out that database, it also helps because then you can have a mechanism that shows if/when data is missing and that the user can fill it out.

Of course, if that's the case, then I'd recommend (because it may be difficult to fully fill out the fields if some information doesn't match any of the given headings) to include a "more info" text field that has no text limit and users can fill out any pertinent data. That way, it will be attributed as a note until someone can properly parse through the data and add it into the database as properly as possible, and the user can fill in everything they need to.

  • I'm not sure what it is you are suggesting... I've clarified what I meant by dynamic a bit (that is, not dynamically filling fields, but just showing and hiding them), if that helps. The input is not for a centralized database - rather, the user is filling in parameters to create a module for their own use.
    – Daniel
    Commented Oct 27, 2014 at 23:14
  • Understood. That said, disregard everything I said about the database and keep everything else. TL;DR: Yes, use dynamic fields, but maybe stop at the maximum number of layers you think are necessary and have a final extraneous-data field so users can submit all additional data in a notepad-like setting that doesn't fit in the available fields.
    – Jamezrp
    Commented Oct 28, 2014 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.