I disagree with the idea of having a default, blank template instance: it means that, if the user just hits "save" without removing that instance, it will be added to the page that's created - which is most likely not what the user intended.

You could argue that template instances in the form that contain no data should be ignored, and not added to the page - but that creates its own problems. And the template instance won't necessarily be blank, anyway - it could contain inputs with default values.

You are correct of course. However, I hope that the test for "no field" filled would be easy enough to implement. For the start, I would be happy enough if the blank forms only work if there are no default values. Ultimately, though with higher reprogramming efforts, it would also be possible to only store it if at least one field differs from the default value (blank or as specified). This is how other form-based software seems to have implemented this problem.

By the way, can you point to any examples of a form that already has an instance there when you go to fill it out? That seems like weird design.

(Semantic forms does that for the main form, so why is it weird?)

For subforms my experience is that at least one row ready to insert is usual. But of course what is "usual" is difficult to prove, and depends on the kind of software one regularly uses.

Perhaps foremost: phpmyadmin is a good example that allows to set more than 1 ready to be inserted (default is 2, can be set higher).

In a brief search for ready-to-show screen shots I found the following examples with subforms already prepared for inserting, without pressing an add-button first:

JS: http://viralpatel.net/blogs/2009/03/dynamically-add-remove-rows-in-html-table-using-javascript.html -- see image and bottom for live.

http://www.developer-corner.com/2011/06/cloning-dijit-widgets.html

ASPX: http://www.4guysfromrolla.com/articles/021203-1.aspx

ASPX: http://aspalliance.com/946_Extended_GridView_Control.5

ASPX: http://www.codeproject.com/KB/grid/usingdatagrid.aspx

ASPX: http://weblogs.asp.net/hajan/archive/2011/08/20/trigger-update-to-jquery-tablesorter-on-dynamically-modified-table.aspx

Flex: http://www.adobe.com/devnet/flex/testdrive/articles/2_modify_the_database.html

twiki: http://support.avetticommerce.com/twiki/bin/view/Documentation/C7ContactUsSetupGuide

drupal:
http://xebee.xebia.in/2011/06/14/drupal-webform-add-a-dynamic-select-option-list/

Hi - wow, that's an impressive bit of research you've done. And you got me on the Semantic Forms Special:CreateTemplate page - I forgot about that one! I still think no instances at the beginning is the way to go, though. It looks to me like all the forms you cited differ from SF forms in at least one of three ways:

1. Most importantly, in most of these cases hitting the "Add" button actually adds the record to the database - and there's only ever one blank instance form; never zero and never more than one. That's just a different interface approach. (There's also the related approach where hitting "Add" doesn't actually add a record, but it *looks* like it does - each added row looks permanent until you hit its "Edit" button. Interface-wise, that's basically the same thing.)

2. In other cases, the form requires at least one row to be filled out - so there's no harm with starting a row. (Although maybe you meant for the "minimum" parameter to also require that number of instances?)

3. In yet other cases, like SF's Special:CreateTemplate, it basically works like SF's regular forms do - but the difference is that the system knows in advance what the data looks like, and knows that it can ignore instances that have certain fields left blank. For the case of SF's regular forms, I just don't know of any way for SF to know when to ignore an instance.

We would like to give the user an intuitive indication of the kind and form of data that can be entered into a repeatable subform. The basic problem at the moment is that the user does not see the fields she or he might be able to enter. There is no way of learning the options other than hitting a button first, which normally requires a preexisting understanding what to expect.

Furthermore, in many cases, only a single record will actually be entered, and from a user perspective it is illogical that the fields to do this are not visible, whereas other fields are.

(In reply to comment #5)

1. Most importantly, in most of these cases hitting the "Add" button actually

True for ASPX, but not necessarily a good design. I prefer your "add another" button (but it should be another to one existing not another of nothing).

there's only ever one blank instance form; never zero and never more than one.

There were examples to the contrary. Also phpmyadmin allows more than 1 (but with a go-button each).

For the case of SF's regular forms, I just
don't know of any way for SF to know when to ignore an instance.

Why does "don't save if completely empty" not work for a start? It would be ok if it does not combine with default values for the beginning.

Also, I do think it is important to keep the option to start with 0 rows visible. It can stay the default if you prefer (but then perhaps change the default label of the "add another"-button...).

Hi,

Why does "don't save if completely empty" not work for a start? It would be ok
if it does not combine with default values for the beginning.

I just don't think you can assume that - there can be cases where having an empty instance is what the user wants to do. I actually know of at least one case where that's true: on the wiki I run, Discourse DB. Here's an example:

http://discoursedb.org/w/index.php?title=The_Boston_Globe&action=formedit

Leaving the "Wikipedia" template blank means "link to the article on Wikipedia that has the same name as this wiki page".

I understand. I think this is rare, but it is a valid legacy use of semantic forms.

Which would still leave the option to only execute the test for
MultipleMinimum=>0

Which other options would be available to show users what data entry options they have? I am unhappy with the idea to have to put a screenshot above the subform...

PS: We also tried to let the multiple form create rows of a table, so that the table headers are above it and visible, but this is not possible either with the present design of semantic forms.

Legacy use? I wouldn't call it that...

Just to clarify: when you talk about a "minimum" value, do you also mean that the form would not allow less than that number? Because if so, there's already a feature request to allow setting both a minimum and maximum allowed - see here:

https://bugzilla.wikimedia.org/show_bug.cgi?id=19979

Just to clarify: when you talk about a "minimum" value, do you also mean that
the form would not allow less than that number? Because if so, there's already
a feature request to allow setting both a minimum and maximum allowed - see
here:

No, the name I gave it seems to be misleading. I mean a minimum_display_instances
not sure how to call it best, you would know your nomenclature best.

If I have a literature template, I would like the user to directly offer 3 author lines. Empty being ignored. Not, as present, zero.

But the > 1 is just convenience. For the 0 or 1 case, i.e. for both cases, I see a vital need.

Hi - if you care to humor me further: what is the importance of having the user see the form section for a template instance ahead of time? After all, if (to take your example) author data is stored using a multiple-instance template, and a book has two authors, then two such instances need to be added to the page - it doesn't matter what the form input looks like. So why does it help for the user to see it ahead of time?

In my view the importance is orientation and feedback on what is possible. Users don't think in terms of multiple instances, and do not (and I believe should not) notice any difference between a field01, field02, field03 denormalization and a 1:n information model.

The case of "author" is relatively simple and, since a core item, unlikely to be overlooked. However, even here, a user will initially scan the input forms for entry choices (where does my information belong in this form), not additional action buttons. I believe even advanced users will start looking at the action buttons as entry possibilities only relatively late.

(Aside: For the author example, or keywords, I consider it actually desirable to have more than one data entry field per author or keyword, which is why I propose a convenience setting of allowing > 1 initial instances. However, this is a separate issue from providing any field at all.)

In our case our motivation is a little bit higher than in the author case, because we have complex relations, that actually are abstract concepts, not easily described in a single word on a button. Example: a relation expression host plant, pathogen/pest, country of occurrence and quarantine status. Domain users seeing these 4 fields learn the data entry strategy much easier, than with just showing a button.

However, even in the http://discoursedb.org/ example you pointed to above, I understood the concept only after pressing the button (that is, on a new form:
http://discoursedb.org/wiki/Special:FormEdit/Source/Test
"Wikipedia articles - Add another" is plain illogical. After pressing the illogical "add another", I suddenly see this is a single field, not 5 fields with some semantics, it seems to be about setting a relation, not about describing wikipedia articles, I see your prompt "Wikipedia article title (leave blank if equal to this page name):" and I start to understand...

Just submitting a DNA sequence at Genbank (NIH): All the multiple authors/source modifiers/etc. have an add button, but the first line (= 1 instance of the subform) is immediately visible and ready for user entry...

And the source modifier are a good case: would you know what a source modifier is, without having access to a picklist of available modifier types?

I didn't understand that last question (maybe because I don't know what a source modifier is :) ), but I still can't get over what I see as the main stumbling block, which is: I don't know if there's any way for the software to know, with certainty, that a template instance whose fields are all blank (or default) should be ignored.

(The point of "source modifier" was that probably no-one understands what that is, until you see the fields that make up this record (a repeated subform with multiple fields in each row), including a picklist of modifier terms).

I believe defining: if minimum_display_instances is > 0, then any empty subform instance will be removed/ignored before saving. If minimum_display_instances=0, then the present behavior (no initial subform instance, empty template saved) remains.

I think that is a reasonable design that is fully backward compatible.